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.
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.
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.
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.
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:
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.
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:
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:
xOpenJIDMrootOid OBJECT IDENTIFIER ::=
{ iso(1) member-national-body bgcolor="#FFFFFF"(2) bsi(826) disc(0) xopen(1050) jidm(9) }
jIDM<document>oid OBJECT IDENTIFIER ::= { xOpenJIDMrootOid (<uuid>) }
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):
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.
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 }
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:
Given an operation
foobar
which is the second operation defined in the
first module of the specification, its OID value will be:
foo OBJECT IDENTIFIER ::= { jIDMdocMod1ManagedObjectClass 1 }
foobar OBJECT IDENTIFIER ::= { jIDMdocMod1Action 2 }
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 "--".
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.
| CORBA IDL | GDMO/ASN.1 |
|---|---|
| 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) |
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:
where <super-classes> are those
of the interface or "jIDMbaseDocument:corbaObject"
if none is specified.
<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> };
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 3.1.5.9).
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.
<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:
Any collisions in attribute names within the module are resolved using sequential "-<n>" suffixes, where <n> increases from 1, as required to disambiguate.
<operation-name>[-<n>] ACTION
[WITH INFORMATION SYNTAX
<IDL-module-name>-ASN1.<operation-name>[-<n>];]
[WITH REPLY SYNTAX
<IDL-module-name>-ASN1.<operation-name>[-<n>];]
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.
Thus, each IDL exception declared in an IDL interface will be translated
into a GDMO PARAMETER template with the
context of SPECIFIC-ERROR:
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.
<exception-name>[-<n>] PARAMETER
CONTEXT SPECIFIC-ERROR
WITH SYNTAX <IDL-module-name>-ASN1-<exception-name>[-<n>]
REGISTERED AS { <parameter oid> };
The corbaStandardException specific error parameter,
defined in the JIDM base GDMO document (see
CORBAName ::= SEQUENCE OF SEQUENCE {
id GRAPHIC STRING,
val GRAPHIC STRING
}
The name binding template is defined as follows:
corbaSystem-corbaObject NAME BINDING
SUBORDINATE OBJECT CLASS corbaObject AND SUBCLASSES;
NAMED BY
SUPERIOR OBJECT CLASS corbaSystem AND SUBCLASSES;
WITH ATTRIBUTE corbaName;
REGISTERED AS { jIDMbaseDocumentNameBinding 1 };
For each IDL attribute type, operation argument type, and for each function return value type, generate an ASN.1 typed as in the following:
| CORBA IDL | GDMO/ASN.1 |
|---|---|
| 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 |
| any | ANY DEFINED BY or |
| 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 |
| CORBA IDL | GDMO/ASN.1 |
|---|---|
| struct | SEQUENCE |
| union | Choice (with ASN.1 TAGs) |
| enum | ENUMERATED |
| array | SEQUENCE OF (with sizeConstraint subtype) |
| sequences | SEQUENCE OF (with optional SizeConstraint |
| subtype for IDL bounds) |
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.
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:
A ::= SEQUENCE {
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),
black(1)}
}
}
The resulting mapping is to the
CORBAANY
production:
CORBAANY ::= SEQUENCE {
identifiedTypeOID OBJECT IDENTIFIER,
identifiedTypeValue ANY DEFINED BY identifiedTypeOID
}
freeFormCORBAANYSyntax OBJECT IDENTIFIER ::= {jIDMbaseDocumentASN1Module 2 1}
for use in the
CORBAANY
production, described in
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.
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
| 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 */ |
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] ;
};
};
};
-- 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
int1 MANAGED OBJECT CLASS
DERIVED FROM "JIDMbaseDocument":corbaObject;
CHARACTERIZED BY int1Package PACKAGE;
REGISTERED AS { exoMod1ManageObjectClass int1(1) };
-- ASN.1 Module definitions
example-ASN1 { exoMod1ASN1Module 1}
DEFINITIONS ::= BEGIN
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}
END
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
int1 MANAGED OBJECT CLASS
DERIVED FROM "JIDMbaseDocument":corbaObject;
CHARACTERIZED BY int1Package PACKAGE
ATTRIBUTES
a GET-REPLACE PARAMETERS corbaStandardException,
b GET PARAMETERS corbaStandardException,
c GET-REPLACE PARAMETERS corbaStandardException;
ACTIONS
act1 PARAMETERS reject, corbaStandardException;;;
REGISTERED AS { exo2Mod1ManagedObjectClass 1 };
a ATTRIBUTE
WITH ATTRIBUTE SYNTAX example2-ASN1.A;
MATCHES FOR EQUALITY, ORDERING ;
REGISTERED AS { exo2Mod1Attribute 1 };
b ATTRIBUTE
WITH ATTRIBUTE SYNTAX example2-ASN1.B;
MATCHES FOR EQUALITY;
REGISTERED AS { exo2Mod1Attribute 2 };
c ATTRIBUTE
WITH ATTRIBUTE SYNTAX example2-ASN1.C;
MATCHES FOR EQUALITY, ORDERING ;
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
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX example2-ASN1.Reject;
REGISTERED AS { exo2Mod1Parameter 1 };
example2-ASN1 { exo2Mod1ASN1Module 1 }
DEFINITIONS ::= BEGIN
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}
END
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 }
corbaObject MANAGED OBJECT CLASS
DERIVED FROM "DMI":top;
CHARACTERIZED BY corbaObjectPackage
ATTRIBUTES
corbaName GET;
commonNameAttribute GET;
NOTIFICATIONS
;
REGISTERED AS { jIDMbaseDocumentManagedObjectClass 1 };
corbaSystem MANAGED OBJECT CLASS
DERIVED FROM corbaObject;
CHARACTERIZED BY corbaSystemPackage
ATTRIBUTES
"DMI":SystemTitle GET
"DMI":SystemId GET;
;
REGISTERED AS { jIDMbaseDocumentManagedObjectClass 2 };
corbaName ATTRIBUTE
WITH ATTRIBUTE SYNTAX Common.corbaName;
MATCHES FOR EQUALITY, SUBSTRING, ORDERING;
REGISTERED AS { jIDMbaseDocumentAttribute 1 };
commonNameAttribute ATTRIBUTE
WITH ATTRIBUTE SYNTAX
"Recommendation X.721:1992":Attribute-ASN1Module.SimpleNameType
MATCHES FOR EQUALITY, SUBSTRINGS, ORDERING;
REGISTERED AS {jIDMbaseDocumenbtAttribute 2};
corbaSystem-corbaObject NAME BINDING
SUBORDINATE OBJECT CLASS corbaObject AND SUBCLASSES;
NAMED BY
SUPERIOR OBJECT CLASS corbaSystem AND SUBCLASSES;
WITH ATTRIBUTE corbaName;
REGISTERED AS { jIDMbaseDocumentNameBinding 1 };
corbaStandardException PARAMETER
CONTEXT SPECIFIC-ERROR
WITH SYNTAX Common.CorbaStandardException
REGISTERED AS { jIDMbaseDocumentParameter 1 } ;
Common MODULE { jIDMbaseDocumentASN1module 1 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
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-YES(0),
COMPLETED-NO(1),
COMPLETED-MAYBE(2) }
CorbaStandardException ::= SEQUENCE{
exceptionName IA5STRING, -- standard exception name
minor Ulong, -- minor code for exception
completed Completion-Status
}
END
CORBAAnyModule { jIDMbaseDocumentASN1module 2 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
ObjectInstance FROM CMIP-1 {joint-iso-ccitt ms(9) cmip(1) modules(0) protocol(3) };
CORBAANY ::= SEQUENCE {
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.
FreeCORBAAny ::= SEQUENCE {
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),
tk-nested(-1)
}
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
octetVal OCTET STRING SIZE INTEGER(1),
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
}
END
| Contents | Next section | Index |