Information Object Class (IOC) SQL table structure descriptor (CREATE TABLE statement) IDL grammar specification (BNF rules) IOC field declaration SQL table column descriptor in CREATE TABLE statement (type of a column) IDL grammar production Information Object (IO) SQL table row (INSERT INTO statement) IDL operation declaration IO field definition Cell of SQL table row in INSERT INTO statement (cell value) Portion of IDL operation declaration, typically related to declaration of an operation type code, parameter list, operation return value, or list of exceptions Information Object Set (IOS) (collection of Information Objects) Completely defined SQL table (collection of rows) (see Note 1) IDL interface definition (collection of operations) ASN.1 data type using references to IOC fields parameterized with IOS (typically a collection of semantically related types designating request, response, and exception, all parameterized with the same IOS) High-level format (grammar specification) of a frame (marshalling buffer) carrying CORBA request, response, or exception ASN.1 encoding rules and transfer syntaxes (BER, PER) Low-level encoding of requests, responses and exception indicators suitable for physical transfer over the medium Note: The analogy between IOS and an SQL table is not quite correct.
SQL permits only one instance of a table of given type (OPERATION in the example below), while ASN.1 permits multiple Information Object Sets derived from the same Information Object Class, what should be most correctly related to multiple instances of the same table in terms of SQL (OPERATION in the example below).
This is approximately analogous to a portion of BNF description of some pseudo-IDL syntax of the following form (note that in subsequent examples we will be using real IDL syntax rather than the imaginary one defined by the BNF below): where Integer production resolves to an integer value, Type resolves to a type reference, and ExceptionList resolves to an instance of Information Object Set derived from ERROR Information Object Class (or list of exceptions in case of IDL).
While we know that in real SQL we can't have multiple instances of the same table, let's imagine for the purposes of accuracy of our description that we actually can.
The @ notation (e.g. @opcode) defines correspondence between fields based on the Information Object Set used to parameterize the data type in question.
Unlike IDL operation definition, the correspondence between frames is non-binding and is purely semantical, although it can be exploited by an ASN.1 tool in a tool-specific fashion.
If you carefully examine the ASN.1 example presented in Table 2 and compare it to IDL concepts, you will see one important limitation on the ASN.1 side.
Here is our Request type rewritten with the concept of parameterization in mind: Now the high-level transfer syntax descriptor Request can be parameterized with any arbitrary Information Object Set ("IDL interface") conforming to the Information Object Class specification ("IDL grammar").
Now what we would have otherwise been written as: in the presence of the WITH SYNTAX clause can be rewritten as follows: To fully understand the grammar concept behind the WITH SYNTAX clause, imagine we wrote our OPERATION Information Object Class definition as follows: Then a corresponding Information Object instance for the definition above is to be defined as follows: