GDMO to CORBA-IDL Translation

Figure: Inputs and Outputs for GDMO Specification Translation

Since nicknames will be used as the basis for naming files, generated IDL files will only be reusable in an environments where identical nickname databases are used. Therefore, it is desirable to make the nickname database as standard as possible (for example, have standard nicknames for all registered GDMO documents and their ASN.1 modules). In order to facilitate this, the following nickname selection method is recommended (but not mandatory):

• For documents, use the ITU recommendation number where it exists. For example, DMI would be called X721.

• For ASN.1 modules, the nickname is formed by taking the nickname of the document in which the module occurs, followed by the first three characters of the module label. For example, the Attribute module of X.721 would have the nickname X721Att.
  

• Where more than one module label in a document has the same initial three letters, append a number to the nicknames for the second and subsequent module labels to disambiguate. This means that the first module would have no numeric suffix, the second colliding module would have the suffix "1", the third "2" and so on.

As it is illegal to modify the existing contents of a standard in this context, it is assumed that the nickname always refers to the latest version of the standard. If, for any reason, parts of the original standard are modified in a revision, the last 2 digits of the revision year can be appended to the nickname.

Outline of Translation Algorithm

1. Generate an OMG IDL file for each ASN.1 module that is contained in a given GDMO document and name it with the nickname that has been assigned to the module (see ASN.1 Type to CORBA-IDL Translation ).

2. Generate an OMG IDL file for each GDMO document and name it with the nickname assigned to the document. That file will contain a module that is named the same as the file and contains interfaces generated for each managed object class template defined in the GDMO document and other information described below.

3. Generate up to two OMG IDL files containing interfaces for handling Notifications via push and/or pull model when requested.

It should be noted that the mechanism used to handle Notifications is designed to work with OMG Event Services (see reference COSS). It enables the use of typed or untyped events delivered via push or pull models. This gives maximum flexibility to implementors to select the most appropriate mechanisms.

File Names and IDL Modules

• Each file will start with a comment identifying the GDMO document from which it was generated.

• Definitions contained in IDL generated files must be enclosed within #ifndef ... #endif directives as shown below and will enclose mappings of GDMO template definitions.

  #ifndef _<capitalised_nickname>_IDL_
  #define _<capitalised_nickname>_IDL_
  module <nickname> {
  
  <idl-mapped-macro-invocations>
  
  };
  #endif /* _<capitalised_nickname>_IDL_ */
  

• For each GDMO document, generate an IDL file named <nickname>.idl containing an IDL module named <nickname>, and two IDL file named <nickname>_N.idl and <nickname>_NP.idl to contain interfaces for notifications. Here <nickname> is the nickname that has been assigned to the document.

• For each ASN.1 module that is contained in a given GDMO document, translate it as described in ASN.1 Type to CORBA-IDL Translation .

  It is permissible for an implementation to only generate the mapping for selected classes from an input document. However, if this is done, all the appropriate superclasses must be included. In addition, the full translation must be performed before the selected classes are output in order to ensure that the name disambiguation rules are applied correctly.

• For each ASN.1 module defined in a given GDMO document, add the directive:

  #include "<module_nickname>.idl"
  

  to the corresponding IDL file, where <module_nickname> is the nickname that has been assigned to the defined ASN.1 module.

This approach results in many IDL files being generated. However, the _N and _NP files are generated to provide implementation choice and could all be omitted if untyped event delivery mechanisms are used. In addition, the other files need only be generated once and may be reused by many translated documents. This in turn allows more efficient code generation by the IDL compiler. Since files are of a finer granularity, documents which build on earlier definitions may extract only the portions that they use by import rather than requiring the whole referenced document to be reviewed. As a side benefit, collision between identically named ASN.1 modules may be avoided by using different nicknames for those modules. Module nicknames are not guaranteed to be unique unless they have the unique <nickname> of their containing GDMO document as a prefix. Another side-effect is that references to types imported from other documents need only be scoped by the module's nickname, which must be unique in the environment.

Standard Files for Specification Translation

ASN1Types.idl

contains the base definitions for translating ASN.1 types (see IDL Modules for Builtin ASN.1 Types ).

ASN1Limits.idl

contains the definitions for ASN.1 limits (see ASN1Limits.idl File ).

OSIMgmt.idl

contains everything which is needed to use CMIS services based on the mapping defined in this document.

In addition, the following standard files, should be delivered with an implementation of the GDMO to IDL translator:

X219Rem.idl

ROSE errors

X227ACS.idl

ACSE types

X711CMI.idl

CMIP types

X501Inf.idl

Information framework

Example

• the nickname for the standard X.721 ASN.1/GDMO document (see reference GDMO), will be X721

• X721Att, X721Not, X721Par will be the nicknames assigned to the different ASN.1 modules,

resulting in the following IDL files:

Example: File X721Att.idl

Example: File X721Not.idl

Example: File X721Par.idl

Example: File X721.idl

Example: File X721_N.idl

Example: File X721_NP.idl