9.7 Generated IDL Issues

   During the design of the MOF Model to IDL mapping, several design decisions were made that are explained in this sub clause.

   Identifier naming is an important issue for automatically generated IDL, especially when that IDL is intended to be used by applications written by human programmers. The mapping has to reach a balance between conflicting requirements:

• Syntactic correctness - all identifiers in the mapped IDL must conform to the defined CORBA IDL syntax, and they must all conform to the CORBA scoping and upper/lower casing restrictions.

• User friendliness - identifiers should convey as much information as possible without being overly long.

• Conformance to existing conventions - identifiers should conform to existing stylistic conventions.

   The OMG conventions for IDL identifiers (see “OMG IDL Style Guide: ab/98-06-03?) are based on the notion that an identifier is formed from one or more words in some natural language. The conventions allow digits to be used in words and take account of acronyms. The Style Guide then specifies three different styles for putting some words together as an identifier. In particular:

• Identifiers for IDL module, interface, and types are capitalized. If the name consists of multiple words, each word is capitalized in the identifier.

• Identifiers for IDL operations, attributes, formal parameters, struct, and exception members are all lower-case. If the name consists of multiple words, the words are separated by underscores (“_?) in the identifier.

• Identifiers for IDL constant and enumerator names are all upper-case. If the name consists of multiple words, the words are separated by underscores (“_?) in the identifier.

   The MOF Model represents the “name? of a ModelElement using the MOF String data type; that is, as UTF-16 strings. The IDL mapping typically needs to convert these names (or alternates provided using an “idl_substitute_name? tag) into OMG IDL identifiers for use in a variety of IDL contexts.

   Since the MOF Model (like the UML meta-model) does not restrict ModelElement name strings, not all names can be mapped to legal OMG IDL identifiers. For example, names that include graphic characters or accented letters do not map to IDL identifiers.

   Names that are subject to mapping must consist only of ASCII letters, digits, hyphens (‘-’), underscores (‘_’) and white-space characters, and must conform to the following syntax:

   word ::= [A-Z][A-Z0-9]*[a-z0-9]*

   | [a-z][a-z0-9]*

   white-space::= SP, CR, LF, HT, VT

   non-sig ::= { ‘_’ | ‘-’ | white-space }*

   identifier::= [non-sig] word { non-sig word }* [non-sig]

   The above syntax defines a heuristic for splitting names into a sequence of words. They can then be reassembled into OMG IDL identifiers using the 3 formats below. The “non-sig? characters are non-significant and are discarded.

   NOTE: The behavior of the IDL mapping for names that do not match the above syntax is not specified.

   In Format 1, the first letter of each word is converted into upper case, and other letters remain the same case as input. The words are not separated by other characters. The table below lists some examples of Format 1 identifiers.

   Format 1 is used by the IDL mapping to produce the names of modules and interfaces.

   In Format 2, all letters in each word are converted into lower case. Each word is separated by an underscore “_.? The table below lists some examples of Format 2 identifiers.

   Format 2 is used by the IDL mapping for identifiers for IDL operations, exceptions, attributes, formal parameters, exception members, and members of generated struct types.

   In Format 3, all letters in each word are converted into upper case. Each word is separated by an underscore “_.? The table below lists some examples of Format 3 identifiers.

   Format 3 is used by the IDL mapping for identifiers for IDL constants.

   Literal string values (in String valued Constants) are not subject to word splitting and reformatting. They should be output in the generated IDL as wide-string literals with character escape sequences as required to express the String value as legal IDL.

   The MOF Model allows Attributes, AssociationEnds, References, and Parameters to being single-, optional-, or multivalued depending on the ModelElement’s base type and its multiplicity.

   At various places in the mapped interfaces, it is necessary to pass collections that represent values for the optional- or multi-valued cases. The IDL mapping synthesizes an IDL type for representing these collections. This type is a typedef (i.e., an alias) for an unbounded CORBA sequence of the collection’s base type, where the name of the typedef depends on the corresponding ModelElement’s multiplicity specification.

   For example, for an ordered unique collection, the synthesized collection type would be a “unique list? (or UList) type. The typedef name for a unique list takes the form <ClassifierType>UList (i.e., the name of the collection base type followed by the characters “UList?). For example, if an M2-level Operation returns an ordered, unique list of some Class called “Foo,? then the IDL type for the corresponding operation’s result is declared as follows:

   interface Foo;typedef sequence <Foo> FooUList;

   Similar collection kind naming conventions are used for constructed data types. Thus for a non-ordered unique collection of an enumeration type, the mapping would produce the following:

   enum SomeEnum {e1, e2};typedef sequence <SomeEnum> SomeEnumSet;

   There are four distinct collection type suffixes corresponding to the combinations of the “isOrdered? and “isUnique? flags for an element’s “multiplicity? attribute. The appropriate suffix should be generated whenever <CollectionKind> appears in the IDL templates below.

   Note that the MOF Model specification includes a relevant Constraint on multiplicity values; see the “MustBeUnorderedNonunique? constraint in 7.9.4, “The MOF Model Constraints,? on page 105. This states that when a feature’s multiplicity bounds are [0..1], both the “isOrdered? and “isUnique? are set to false. As a consequence, the <CollectionKind> suffix for a [0..1] collection type is always “Bag.?

   When the base DataType maps to a built-in CORBA data type, the base name for the synthesized collection type is defined as shown in Table 9.3.

   Table 9.3 - Base Names for Synthesized Collections of built-in IDL types

   Declarations for the collection types appear following the IDL declaration for a DataType or the forward IDL declaration for a Class. Declarations for synthesized collection types for technology neutral and CORBA specific primitive data types appear in the “PrimitiveTypes? and “CorbaIdlTypes? modules respectively. The corresponding IDL files will typically be “#included? as required.

   Operations produced by the IDL mapping with collection parameters must ensure that the sequence values supplied and returned have an appropriate number of elements. When collection parameters are sets or unique lists, operations must also ensure that the sequence values contain no duplicates.

   To avoid scoping errors within the mapped IDL, identifier names must be either fully qualified, or partially qualified to an appropriate level. This specification leaves the choice between the use of fully or partially qualified identifiers to the implementor.

   This specification does not prescribe how the generated IDL is organized into files. Therefore, the generation rules do not contain any “#include? statements. An implementor must decide how to organize the generated IDL into files, and must generate appropriate “#include? statements to ensure that the resultant IDL can compile. Similarly, the implementor must generate “#ifndef? guards as required by the OMG style rules.