Previous section.

Inter-domain Management: Specification Translation

Inter-domain Management: Specification Translation
Copyright © 1997 The Open Group

OMG IDL to GDMO/ASN.1 Translation


Mapping from CORBA IDL to GDMO/ASN.1 is simpler in that GDMO/ASN.1 has more expressive power than CORBA IDL.

A CORBA IDL specification consists of one or several input files. A specification may contain global declarations and a possibly empty sequence of IDL modules which themselves can contain declarations, interfaces and nested modules which allow for further nesting. This specification does not support global declarations and requires that all declaration be contained within a module.

A GDMO document consists of a sequence of GDMO templates and/or ASN.1 modules. No further formal structuring is possible.

Outline of the Translation Algorithm

The translation alorithm defined in this chapter applies the following translation rules. It generates:

Nested IDL modules are unravelled to the outermost module.

No templates are generated for attribute groups, behaviour and notifications. Package templates are only generated in-line.

Generated GDMO/ASN.1 Documents

A separate GDMO document is generated for each outermost module of the IDL file.

The translator moves every nested IDL declaration to the GDMO document scope. All IDL datatype declarations are moved into a single ASN.1 module.

Any resulting collisions between identifiers are resolved by appending a suffix "-<n>" where <n> is an increasing integer starting with 1, as necessary within the mapped module.

The CORBA IDL input accepted by the IDL to GDMO translator may contain one or a sequence of outermost IDL modules, which may contain declarations of data types, constants, interfaces and nested modules.

JIDM GDMO Base Document

A single file with the new GDMO document "JIDMbaseDocument" with the necessary basic definitions is part of this specification:

A Managed Object Class used as the inheritance root for all IDL derived managed object classes. (It is a subclass of X721:Top).

A Managed Object Class used as the local naming root for all IDL derived managed object instances. (It is a subclass of corbaObject).

A Name Binding for corbaObject and subclasses under corbaSystem.

An ASN.1 OBJECT IDENTIFIER used as root or prefix for the generated (see Allocation of Object Identifiers ).

Lexical Translation

The alphabet for IDL specifications is based on the ISO Latin-1 standard (reference ISO 8859-1) with a rich set of graphic characters. The character set of GDMO and ASN.1 is more restricted.

For the use in the generated specification itself, the rules for identifiers and constant value declarations are of major concern (see below). The permissible alphabets for strings are mapped as close as possible to the appropriate ASN.1 string types.

Translation of IDL Identifiers to GDMO and ASN.1 Labels

IDL identifiers must start with one alphabetic character and may consist of any sequence of any alphabetic or digit characters or the underbar ("_") character. Identifiers that differ only in the case (upper or lower) of the letters are regarded as equal.

For GDMO and ASN.1, identifiers may consist of letters and digits as in IDL but may contain the dash ("-") instead of the underbar. As additional requirement, GDMO and ASN.1 expect a lower case first letter for structure members and value specifications, and an upper case first letter for ASN.1 Type productions. All GDMO templates must have names beginning in lower case.

The translation algorithm replaces each underbar by a dash and applies the rule for the first letter to all identifiers.

IDL type identifiers are unique within their interfaces with respect to module naming scope. As the nested structure of modules and interfaces will be lost in the generated ASN.1 files, conflicts between these type identifiers may occur. In this case, the string "-[i]" is appended to the second and subsequent colliding identifiers with "i" incremented by one upon each usage. This is similar to the approach taken for the GDMO to CORBA IDL mapping.

For each generated GDMO document, with a given nickname, the translator must produce a text output file, named <nickname>.ide, which contains a line for each IDL identifier translated into corresponding definitions in that GDMO document. Each line of the <nickname>.ide file will have the following three fields, using "," as a field delimiter:

<IDL fully scoped identifier name>,<gdmo identifier used>,<object identifier in string dot notation>

The first and second fields are always present. The third field may not be present if no object identifier has been generated for the IDL identifier.

For ASN.1 production names defined in the ASN.1 module <IDL-module-name>-ASN1, the second field will be scoped as in GDMO SPECIFIC-ERROR.

Allocation of Object Identifiers

The OBJECT IDENTIFIERS for each of the GDMO templates are automatically allocated, given an OBJECT IDENTIFIER value for the IDL specification in which the definitions are contained.

Part of compiling an IDL file into GDMO will require specifying an OBJECT IDENTIFIER root for the IDL file. This OBJECT IDENTFIER root may be obtained through any valid registration authority for ASN.1 OBJECT IDENTIFIER values.

As an alternative, a mechanism1 is described below which will allow a unique identifier to be easily generated. In many IDL environments, a generator of DCE uuid values (uuidgen) is available. DCE uuid values are globally unique 128 bit values. Corresponding values for OBJECT IDENTIFIERS based upon DCE uuid values can be generated below a common root id supplied by The Open Group:

  { iso(1) member-national-body bgcolor="#FFFFFF"(2) bsi(826) disc(0) xopen(1050) jidm(9) }

The actual OID must be based on appending as the next level of the OBJECT IDENTIFIER a uuid generated by the invoker of the translator making use of the DCE tool uuidgen. It should be noted that this approach guarantees unique OIDs under The Open Group JIDM root OID without a further need for registration. In addition, once a single uuid has been generated, the user is free to allocate the resulting sub-tree as they desire:
jIDM<document>oid OBJECT IDENTIFIER ::= { xOpenJIDMrootOid (<uuid>) }

Use of Object Identifiers

Given an OBJECT IDENTIFIER value "jIDM<document>oid" for the IDL specification, separate OBJECT IDENTIFIER values can be generated for each outermost module in the IDL file. The value 0 is reserved, and each successive outermost module takes the next available number, starting with 1 for the first module in the sequence of outermost modules. For example:
jIDMdocMod1        OBJECT IDENTIFIER     ::= { jIDM<document>oid 1 }
jIDMdocMod8        OBJECT IDENTIFIER     ::= { jIDM<document>oid 8 }

Note there is a unique OBJECT IDENTIFIER value for each GDMO document generated from the IDL file. Using jIDMdocMod1 as an example root for the GDMO document corresponding to the first outermost module of the jIDMdocument, it is possible to further derive the following categories, which serve as registration nodes for each category of IDL defined items within the module. It should be noted that these assignments are fully in line with the GDMO standard (see reference GDMO, clause 6.4.3):

jIDMdocMod1ASN1Module         OBJECT IDENTIFIER ::= { jIDMdocMod1 2 }
jIDMdocMod1ManagedObjectClass OBJECT IDENTIFIER ::= { jIDMdocMod1 3 }
jIDMdocMod1Parameter          OBJECT IDENTIFIER ::= { jIDMdocMod1 5 }
jIDMdocMod1NameBinding        OBJECT IDENTIFIER ::= { jIDMdocMod1 6 }
jIDMdocMod1Attribute          OBJECT IDENTIFIER ::= { jIDMdocMod1 7 }
jIDMdocMod1Action             OBJECT IDENTIFIER ::= { jIDMdocMod1 9 }
jIDMdocMod1IDLtype            OBJECT IDENTIFIER ::= { jIDMdocMod1 11 }

At a given nesting level, defined items of a given category (for example, action) are sequentially assigned integers corresponding to relative position in the specification.

The jIDMdocMod1IDLtype is supplied as a local root for assigning OBJECT IDENTIFIER values for each type defined in the module, for use in the ASN.1 ANY type (see below) as identifiers, without resorting to the free form of IDL any representation.

Given an interface foo which is the first interface in the first module, its OID value would be:

foo OBJECT IDENTIFIER ::= { jIDMdocMod1ManagedObjectClass 1 }

Given an operation foobar which is the second operation defined in the first module of the specification, its OID value will be:
foobar OBJECT IDENTIFIER ::= { jIDMdocMod1Action 2 }

Translation of Comments

Mapping of comments is optional. Because the nested modules are unravelled in the translation process, there might be some reordering of the IDL which may fail to re-order the associated comments, thus rendering the translated comments of doubtful value.

IDL uses the same syntax for comments as C++ does: either a full line of text starting from "//" or any portion of the input text between "/*" and "*/".

Both forms are translated into the ASN.1 comment "--".

Translation of Preprocessor Directives

IDL uses the same syntax and inventory of preprocessor directives as C++. As GDMO/ASN.1 does not support any preprocessor directives, the IDL files should be preprocessed according to the normal rules established in the CORBA specification (see reference CORBA).

The identifier file associated with each GDMO document must be consulted to determine the proper GDMO reference or ASN.1 Import for each of the external definitions used within the translated IDL specification file.

Translation of CORBA IDL

Translation of IDL Definitions gives an overview on the mapping of CORBA IDL entities into GDMO templates.

Interface (multiple MANAGED OBJECT (multiple inheritance)
inheritance, no override)
Operation (in, out, and in-out ACTION WITH INFORMATION SYNTAX
parameters, optional return SEQUENCE {(in, and in-out params)}
result value, one-way option) WITH REPLY SYNTAX
  SEQUENCE{return result value,
  (in-out and out params)}
Attribute (get value, set value) ATTRIBUTE (GET, or GET-REPLACE)
Exception (standard and user SPECIFIC ERRORS (with parameters
defined with parameters) carried by ROER processing failure)

Table: Translation of IDL Definitions
Translation of IDL Interfaces

CORBA interfaces are mapped directly to Managed Object Class templates. Each IDL interface is translated into a GDMO managed object class template as in the following:

  <interface-name>[-<n>] MANAGED OBJECT CLASS
    DERIVED FROM <super-classes>
    [CHARACTERIZED BY <interface-name>Package[-<n>] PACKAGE
    [ATTRIBUTES <list of attributes and properties>;]
    [ACTIONS <list of operation names>;]]
  REGISTERED AS { <managed-object-class-oid> };

where <super-classes> are those of the interface or "jIDMbaseDocument:corbaObject" if none is specified.

There is no need to generate a package if an interface contains neither attributes nor operations.

The interface-name, and its corresponding inline package name, is given the "-<n>" suffix, where <n> increases from 1, as required to disambiguate any colliding interface names caused by the nested module unravelling.

The properties of the attributes depend on the readonly token of the IDL attribute. If it is present, the attribute gets the property GET, otherwise the attribute is read-write and it gets the property GET-REPLACE.

If an attribute has its base type as an IDL sequence, then the mapped ASN.1 attribute syntax will be SEQUENCE OF, thus the list of properties may not be extended by ADD-REMOVE, which is only allowed for set-valued attributes. (A set-valued attribute is one whose syntax is SET OF. CMIS has the further restriction that set-valued attributes cannot repeat values (see reference CMIS clause

The GDMO properties SET TO DEFAULT, INITIAL VALUE and PERMITTED VALUE cannot be generated because IDL does offer comparable information. All translated attributes and actions must include the specific error parameter corbaStandardException.

Translation of IDL Attributes
Each IDL attribute declared in an IDL interface will be translated to a GDMO attribute template:
  <attribute-name>[-<n>] ATTRIBUTE
    WITH ATTRIBUTE SYNTAX <IDL-module-name>-ASN1.<attribute-name>[-<n>];
    MATCHES FOR <matching rules>;
  REGISTERED AS { <attribute-oid> };

where <matching rules> is determined based on characteristics of the attribute's base type:

for every type

for integer, real and string types

for string types

cannot be used, since an IDL attribute will never be a set-valued attribute

cannot be used, since an IDL attribute will never be a set-valued attribute.

Any collisions in attribute names within the module are resolved using sequential "-<n>" suffixes, where <n> increases from 1, as required to disambiguate.

Translation of IDL Operations
Each IDL attribute declared in an IDL interface will be translated into a GDMO ACTION template:
<operation-name>[-<n>] ACTION
REGISTERED AS { <action-oid> };

The type of an action information (reply) is a structure of type SEQUENCE which is composed of fields corresponding to all in and inout arguments ( retVal, inout and out arguments). The name of each field the name of the corresponding formal parameter of the operation. The name of the field that represent the operation return value is retVal.

The exceptions raised on the IDL operations must be mapped to specific errors for the ACTION when used in the package definition.

Translation of IDL Exceptions
IDL exceptions are defined and are used in the context of a method invocation as form of error return. This sematics is different from that of GDMO notifications which spontaneously indicate an event (not only an error) from the remote side.

Thus, each IDL exception declared in an IDL interface will be translated into a GDMO PARAMETER template with the context of SPECIFIC-ERROR:

<exception-name>[-<n>] PARAMETER
    WITH SYNTAX <IDL-module-name>-ASN1-<exception-name>[-<n>]
REGISTERED AS { <parameter oid> };

The exception name is appended with a "-<n>" suffix, with <n> increasing from 1 as required to disambiguate naming collisions within the outermost IDL module.

The corbaStandardException specific error parameter, defined in the JIDM base GDMO document (see JIDM Base GDMO Document ) must be added as a SPECIFIC-ERROR parameter for all translated IDL operations and attributes.

Name Bindings

As the IDL world does not know about name bindings and introduces naming/containment hierarchies through the use of COSS:naming services, the mapping defines a flat naming hierarchy, that is, every generated GDMO MOC will be named by a common root object called JIDM:corbaSystem with a naming attribute defined as:
                 id GRAPHIC STRING,
                 val GRAPHIC STRING

The name binding template is defined as follows:
corbaSystem-corbaObject  NAME BINDING
    WITH ATTRIBUTE  corbaName;
REGISTERED AS { jIDMbaseDocumentNameBinding 1 };

Mapping CORBA IDL Data Type Definitions

The following sections explain how CORBA IDL interface definitions can be mapped onto GDMO/ASN.1.

Translation of IDL Data Types

Translation of IDL Base Types
The generated common ASN.1 modules should import the common IDL base types as defined in the jIDMbaseDocument ASN1Module, as required by the translated IDL types. This will allow the translator to not include ranges each time it translates an integer and thus renders the generated code clearer.

For each IDL attribute type, operation argument type, and for each function return value type, generate an ASN.1 typed as in the following:

integer (long, short, Integer (with optional subtype_spec)
unsigned long, unsigned short)
floating point (float, double) Real
char GraphicString
string GraphicString
octet OCTET STRING (size constraint of 1)
boolean BOOLEAN
 SEQUENCE{ typecode, anyValue }
 See discussion below.
string GraphicString
object <or any other ObjectInstance (X.500 Distinguished name)
object reference> Use one of the names from the OMG name
 service, and convert to X.500 format

Table: Type Mapping
Translation of IDL Type Constructors

union Choice (with ASN.1 TAGs)
array SEQUENCE OF (with sizeConstraint subtype)
sequences SEQUENCE OF (with optional SizeConstraint
 subtype for IDL bounds)

Table: Constructor Mapping

When translating complex IDL structures (structures containing structures, sequence ..., or sequence of sequence ... ), no generation of intermediate types is required. Keep one ASN.1 type per one IDL type.

When multiple declarators are used, generate a type/constant for each declarator.

Examples for Constructed Types

module m{
    typedef struct A{
        sequence <string <10>, 15 >  u;
        long  v[10][20];
        struct B {
            long x;
            short y;} w;
        sequence<long,10>  z[3];
        union B switch (long){
            case 1: short x;
            case 2: enum C{ red, black } y;
        } q;

the translation to ASN.1 is:
          u SEQUENCE SIZE(15) OF GraphicString(SIZE(10)),
          v SEQUENCE SIZE(10) OF SEQUENCE SIZE(20) OF Long,
          w SEQUENCE {
              x Long ,
              y Short },
          z SEQUENCE SIZE(3) OF SEQUENCE SIZE(10) OF Long,
          q CHOICE {
              x Short,
              y ENUMERATED { red(0),

Provision of CORBA ANY Type in GDMO/ASN.1

The CORBA IDL Any type is able to contain any structured value. In addition to the value, the type of the value and its components can be determined during run time and be interpreted during access. This is similar to the ASN.1 ANY DEFINED BY type, but in contrast, the type information is outside of the scope of the ASN.1 specifications. For the translation, a mapping from IDL Any to ASN.1 ANY DEFINED BY is needed.
ASN.1 Syntax for CORBA ANY Type Parameters
Given the OBJECT IDENTIFIER allocation scheme provides an OBJECT IDENTIFIER for CORBA IDL Typedefs in CORBA specifications which are translated to GDMO, the generated OBJECT IDENTIFIER can be used to identify each IDL TypeDef. This object identifier can serve as the typeCode in an ASN.1 representation of CORBA any, based on the ANY DEFINED BY construct.

The resulting mapping is to the CORBAANY production:

                 identifiedTypeOID OBJECT IDENTIFIER,
                 identifiedTypeValue ANY DEFINED BY identifiedTypeOID

Free Form Representation of CORBA Any Parameters
For cases where CORBA ANY is used to carry a parameter for which there is no translated CORBA IDL module in existence to provide the identifiedTypeOID, a recursive representation of type codes and ANY values can be used. For such uses of CORBA ANY, this specification registers an ASN.1 OBJECT IDENTIFIER VALUE:
freeFormCORBAANYSyntax OBJECT IDENTIFIER ::= {jIDMbaseDocumentASN1Module 2 1}

for use in the CORBAANY production, described in ASN.1 Syntax for CORBA ANY Type Parameters , to signal that the identifiedTypeValue has the free form ANY type syntax described in Free Form Representation of CORBA Any Parameters .

The ASN.1 syntax production for a free form CORBA ANY value, can be used for CORBA ANY when the associated CORBA Type definition is not within a translated CORBA IDL specification (that is, does not have a registered OBJECT IDENTIFIER value for the type. Although more complex, this alternative conveys information on the contents of Any values which have types defined at run time (that is, not defined within a translated CORBA specification).

The ASN.1 syntax is specified in the FreeCORBAAny production in the ASN.1 module in this Chapter.

Free Form Type Code Representation in ASN.1
Conceptually, a CORBA IDL TypeCode is a recursive structure, which allows any IDL defined type to be represented. It is used to unravel the anyValue field in the Any type.

The syntax of Type codes is specified by the TCKind, TCParm and TypeCode productions in the ASN.1 module in this Chapter.

To represent recursive types (for example, struct foo { sequence <foo> bar } ) a special TCKind value (-1) is used. Its parameter list includes an integer which indicates the number of upward nest levels required to access the recursively referenced type code.

The parameter list is populated for the various KINDs as indicated in Type Code Kinds and Associated Parameter Lists , which allows for all CORBA 2.0 valid any parameter types to be passed using the ASN.1 syntax for Type code.

Free Form CORBA Any Value Representation in ASN.1
The value for the Any type is represented as a nested choice structure, which can be unraveled using the type code information. The ASN.1 syntax is specified in the CORBAAnyValue production specified in the ASN.1 module at the end of this chapter.

KIND PARAMETER LIST "{...}" (denotes repetition of contents)
tk-null "none"
tk-void "none"
tk-short "none"
tk-long "none"
tk-ushort "none"
tk-ulong "none""
tk-float "none"
tk-double "none"
tk-boolean "none"
tk-char "none"
tk-octet "none"
tk-any "none"
tk-TypeCode ""none"
tk-principal "none"
tk-interfaceRef string(repository ID), string (name)
tk-struct string(repository ID), string(name), integer(count)
tk-except { string(member name), TypeCode(member type) }
tk-union string(repository ID), string(name), TypeCode(discriminant type),
 integer(default used), integer(count),
 { anyVal(label-value), string(member name), TypeCode(member type) }
 /*Note: type of label anyVal determined by third parameter,
 discriminant type */
tk-enum string(repository ID), string(name), integer(count),
 { string(member name }
tk-string integer(max length) /* for unbounded strings, this value is zero */
tk-sequence TypeCode(element type), integer(bounds)
tk-array TypeCode(element type), integer(length)
tk-alias string(repository ID), string(name), TypeCode
tk-nested integer(number of nest levels up to referenced type code)
 /*use to represent recursive type definitions */

Table: Type Code Kinds and Associated Parameter Lists


Example 1

Assume a simple CORBA IDL specification containing the module "Example" with an assigned object identifier of "exo":
module example
{    /* only some data types */
    interface int1
        const long c1 = 6;

        enum ExEnum { x, y, z};
        struct ExStruct{
            long x;
            boolean y;

        union ExUnion switch(long){
            case 1:  boolean state;
            case 2:  ExStruct info[55] ;

This results in the following GDMO/ASN.1 definitions:
-- allocated object identifier

   exo            OBJECT IDENTIFIER ::= { xopenJIDMrootOid <x> }
   exoMod1                   OBJECT IDENTIFIER ::= {exo 1 }
   exoMod1ASN1Module         OBJECT IDENTIFIER ::= { exoMod1 2 }
   exoMod1ManagedObjectClass OBJECT IDENTIFIER ::= { exoMod1 3 }
   exoMod1Package            OBJECT IDENTIFIER ::= { exoMod1 4 }
   exoMod1Parameter          OBJECT IDENTIFIER ::= { exoMod1 5 }
   exoMod1NameBinding        OBJECT IDENTIFIER ::= { exoMod1 6 }
   exoMod1Attribute          OBJECT IDENTIFIER ::= { exoMod1 7 }
   exoMod1AttributeGroup     OBJECT IDENTIFIER ::= { exoMod1 8 }
   exoMod1Action             OBJECT IDENTIFIER ::= { exoMod1 9 }
   exoMod1IDLtypes           OBJECT IDENTIFIER ::= { exoMod1 11 }

-- GDMO template definitions

      DERIVED FROM  "JIDMbaseDocument":corbaObject;
   REGISTERED AS { exoMod1ManageObjectClass int1(1) };

-- ASN.1 Module definitions
   example-ASN1  { exoMod1ASN1Module 1}

      IMPORTS  ObjectInstance  FROM  ... ;
   -- need to incorporate the common base types mapping here
      c1    INTEGER  ::= 6
      ExEnum         ::= ENUMERATED { x(0), y(1), z(2)}
      ExStruct       ::= SEQUENCE{ x INTEGER, y BOOLEAN}
      ExUnion        ::= CHOICE { state BOOLEAN,
                                         info SIZE(55) ExStruct}


Example 2

Assume a simple CORBA IDL specification containing the module "Example2" with an assigned object identifier of "exo2":
module example2
    const long c1 = 6;

    typedef  long ExArray[10];

    typedef sequence <long, c1> limitedSeq;

    exception reject { long reason; string  info;};

    interface int1
                 attribute long a;
        readonly attribute sequence<octet> b;
                 attribute float  c;

        long act1 ( in ExArray a, out limitedSeq b, inout ExArray c )
               raises (reject);


This results in the following GDMO/ASN.1 definitions:
-- allocated object identifier

     exo2             OBJECT IDENTIFIER ::= { xopenJIDMrootOid <x> }
     exo2Mod1                   OBJECT IDENTIFIER ::= { exo2 1 }
     exo2Mod1ASN1Module         OBJECT IDENTIFIER ::= { exo2Mod1 2 }
     exo2Mod1ManagedObjectClass OBJECT IDENTIFIER ::= { exo2Mod1 3 }
     exo2Mod1Package            OBJECT IDENTIFIER ::= { exo2Mod1 4 }
     exo2Mod1Parameter          OBJECT IDENTIFIER ::= { exo2Mod1 5 }
     exo2Mod1NameBinding        OBJECT IDENTIFIER ::= { exo2Mod1 6 }
     exo2Mod1Attribute          OBJECT IDENTIFIER ::= { exo2Mod1 7 }
     exo2Mod1AttributeGroup     OBJECT IDENTIFIER ::= { exo2Mod1 8 }
     exo2Mod1Action             OBJECT IDENTIFIER ::= { exo2Mod1 9 }
     exo2Mod1IDLtypes           OBJECT IDENTIFIER ::= { exo2Mod1 11 }

-- GDMO template definitions

     DERIVED FROM  "JIDMbaseDocument":corbaObject;
             a GET-REPLACE PARAMETERS corbaStandardException,
             b GET PARAMETERS corbaStandardException,
             c GET-REPLACE PARAMETERS corbaStandardException;
             act1  PARAMETERS reject, corbaStandardException;;;
   REGISTERED AS { exo2Mod1ManagedObjectClass 1 };

   REGISTERED AS { exo2Mod1Attribute 1 };

   REGISTERED AS { exo2Mod1Attribute 2 };

   REGISTERED AS { exo2Mod1Attribute 3 };

   act1  ACTION
     PARAMETERS  reject  -- not sure if belongs here, as opposed to
     package template
     WITH INFORMATION SYNTAX  example2-ASN1.Act1Info;
     WITH REPLY SYNTAX  example2-ASN1.Act1Reply;
   REGISTERED AS { exo2Mod1Action 1 };

   reject  PARAMETER
     WITH SYNTAX  example2-ASN1.Reject;
   REGISTERED AS { exo2Mod1Parameter 1 };

   example2-ASN1  { exo2Mod1ASN1Module 1 }
      IMPORTS ObjectInstanceType
         FROM {joint-iso-ccitt ms(9) cmip(1) modules(0) protocol(3) };
    -- need to incorporate the base type mapping here
      c1   INTEGER  ::= 6
      ExArray       ::= SEQUENCE SIZE(10) OF INTEGER
      LimitedSeq    ::= SEQUENCE SIZE(c1) OF INTEGER
      Reject        ::= SEQUENCE { reason INTEGER,
                                     info   OCTET STRING}

      A        ::= INTEGER
      B        ::= SEQUENCE OF IdlOctet
      C        ::= REAL

      Act1Info ::= SEQUENCE { a SEQUENCE OF ExArray,
                                           c ExArray}

      Act1Reply::= SEQUENCE { retVal INTEGER,
                                 b LimitedSeq,
                                 c ExArray}

JIDM Base GDMO Document

This section gives the full specification of the JIDM base document for use with GDMO/ASN.1 specifications which have been translated from CORBA IDL specifications.

Assigned X/Open JIDM Object Identifier

jIDMbaseDocument                   OBJECT IDENTIFIER ::= 
          {iso(1) member-national-body bgcolor="#FFFFFF"(2) bsi(826) disc(0) xopen(1050) jidmbase(10)}
jIDMbaseDocumentASN1Module         OBJECT IDENTIFIER ::= { jIDMbaseDocument 2 }
jIDMbaseDocumentManagedObjectClass OBJECT IDENTIFIER ::= { jIDMbaseDocument 3 }
jIDMbaseDocumentPackage            OBJECT IDENTIFIER ::= { jIDMbaseDocument 4 }
jIDMbaseDocumentParameter          OBJECT IDENTIFIER ::= { jIDMbaseDocument 5 }
jIDMbaseDocumentNameBinding        OBJECT IDENTIFIER ::= { jIDMbaseDocument 6 }
jIDMbaseDocumentAttribute          OBJECT IDENTIFIER ::= { jIDMbaseDocument 7 }
jIDMbaseDocumentAction             OBJECT IDENTIFIER ::= { jIDMbaseDocument 9 }
jIDMbaseDocumentIDLtypes           OBJECT IDENTIFIER ::= { jIDMbaseDocument 11 }

JIDM Base Document Managed Object Class Template

   CHARACTERIZED BY corbaObjectPackage
         corbaName  GET;
         commonNameAttribute GET;
REGISTERED AS { jIDMbaseDocumentManagedObjectClass 1 };

   DERIVED FROM  corbaObject;
   CHARACTERIZED BY corbaSystemPackage
         "DMI":SystemTitle   GET
         "DMI":SystemId      GET;
REGISTERED AS { jIDMbaseDocumentManagedObjectClass 2 };

JIDM Base Document Attribute Templates

corbaName  ATTRIBUTE
   WITH ATTRIBUTE SYNTAX  Common.corbaName;
REGISTERED AS { jIDMbaseDocumentAttribute 1 };

commonNameAttribute ATTRIBUTE
      "Recommendation X.721:1992":Attribute-ASN1Module.SimpleNameType
REGISTERED AS {jIDMbaseDocumenbtAttribute  2};

JIDM Base Document Name Binding Templates

The following name binding is provided for use when the IDL interface has a COS name. Other name bindings may be defined for alternative naming schemes. This is why there are two naming attributes in corbaObject.

corbaSystem-corbaObject  NAME BINDING
    WITH ATTRIBUTE  corbaName;
REGISTERED AS { jIDMbaseDocumentNameBinding 1 };

JIDM Base Document Parameter Templates

corbaStandardException  PARAMETER
    WITH SYNTAX Common.CorbaStandardException
REGISTERED AS { jIDMbaseDocumentParameter 1 } ;

JIDM Base Document ASN.1 Module

Common MODULE { jIDMbaseDocumentASN1module 1 }

    corbaName ::= SEQUENCE OF SEQUENCE {
                     id  GRAPHIC STRING,
                     val GRAPHIC STRING
    Octet ::= OCTET STRING (SIZE(1))
    Long  ::= INTEGER (-2147483648..2147483647)
    ULong ::= INTEGER (0..4294967295)
    Short ::= INTEGER (-32768..32767)
    UShort::=INTEGER (0..65535)

    Completion-Status ::= ENUMERATED {
                          COMPLETED-MAYBE(2) }

    CorbaStandardException ::= SEQUENCE{
                 exceptionName IA5STRING, -- standard exception name
                 minor Ulong,  -- minor code for exception
                 completed  Completion-Status


ASN.1 Module for Representing CORBA ANY Type Parameters

CORBAAnyModule { jIDMbaseDocumentASN1module 2 }
  ObjectInstance FROM CMIP-1 {joint-iso-ccitt ms(9) cmip(1) modules(0) protocol(3) };

    identifiedTypeOID OBJECT IDENTIFIER,
    identifiedTypeValue ANY DEFINED BY identifiedTypeOID

  freeFormCORBAANYSyntax ::= OBJECT IDENTIFIER { jIDMbaseDocumentASN1Module 2 1 }

  -- This OBJECT IDENTIFIER value serves as identifiedTypeOID for the
  -- following free form value syntax for representing CORBAANY parameters
  -- which do not have their own OID.

    typeCodeField TypeCode,
    anyValueField CORBAAnyValue

  TCKind ::= INTEGER {
    tk-null (0), tk-void(1), tk-short(2), tk-long(3),
    tk-ushort(4), tk-ulong(5), tk-float(6), tk-double(7),
    tk-boolean(8), tk-char(9), tk-octet(10), tk-any(11),
    tk-TypeCode(12), tk-Principal(13), tk-interfaceRef(14),
    tk-struct(15), tk-union(16), tk-enum(17), tk-string(18),
    tk-sequence(19), tk-array(20), tk-alias(21),tk-except(22),

  TCParm ::= CHOICE {
    tcParm-string GeneralString,
    tcParm-typeCode TypeCode,
    tcParm-integer INTEGER,
    tcParm-anyVal [3] CORBAAnyValue

  TypeCode :: = SEQUENCE {
    tcKind TCKind,
    numberTCParms INTEGER,
    tcParmList SEQUENCE OF TCParm -- may be empty (if tcKind <= 13)

  --the contents of the parameter list for each TCKind is specified above.

  CORBAAnyValue ::= CHOICE {
    nullVal [0] NULL,
    voidVal [1] NULL,
    intVal INTEGER, -- used for short, long, ushort and ulong IDL types
    realVal REAL,   -- used for float and double IDL types
    booleanVal BOOLEAN,
    stringVal GeneralString,
      -- used for string and char IDL types, size not constrained
      -- for char due to escape sequences
    typeCodeVal [8] TypeCode,
    interfaceRefVal [9] ObjectInstance,
    structVal [10] SEQUENCE OF CORBAAnyValue,
    unionVal [11] SEQUENCE{ discrimVal CORBAAnyValue, valChosen CORBAAnyValue},
    enumVal INTEGER, -- position in enumeration definition, start with 1
    sequenceVal [13] SEQUENCE OF CORBAAnyValue,
    arrayVal [14] SEQUENCE OF CORBAAnyValue,
    principalVal [15] OCTET STRING, -- contents depend on implementation
    anyVal [16] SEQUENCE { typeCodeVal TypeCode,
      anyValField CORBAAnyValue } -- nested any


It is possible that additional mechanisms of generating unique OIDs under a common root may be defined in the future.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index