Information Object Class (ASN.1) - Parameterization

Parameterization

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.

Our example ASN.1 data types which we agreed to compare to a high-level CORBA/IDL transfer syntax specification are limited to definition of such transfer syntax only for a single instance of what we compared to an IDL interface (Information Object Set in ASN.1 terms).

In other words, such transfer syntax is not generic and it is not reusable.

With the current set of known tools you can't define such a transfer syntax in a generic way in, say, ASN.1 specification A and then reuse it in ASN.1 specifications B and C that define concrete application-specific "IDL interfaces" on which A does not depend.

The reason for the current limitation is that we currently hard-code our Information Object Set (MyWarehouseOps in case of OPERATION, or MyErrorSet in case of ERROR) into our ASN.1 data types (high-level transfer syntax specification).

Now we need to make one last step to have a complete and fully functioning system. We need to introduce a concept of type parameterization using Information Object Set as a type formal parameter.

Here is our Request type rewritten with the concept of parameterization in mind:

Request {OPERATION : OpSet} ::= SEQUENCE { invokeId INTEGER, opcode OPERATION.&operationCode ({OpSet}), req-pars OPERATION.&InvocationParsType ({OpSet} {@opcode}) }

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").

Therefore, we can now instantiate it for any Information Object Set as follows:

Request1 ::= Request{MyWarehouseOps} Request2 ::= Request{MyOtherSetOfOps} -- etc.