Information Objects

---

Information Objects and Classes are used to define multi-layer protocols in which "holes" are defined within ASN.1 types for passing message components to different layers for processing. These items are also used to define the contents of various messages that are allowed in a particular exchange of messages. The ASN1C compiler extracts the types involved in these message exchanges and generates encoders/decoders for them. The "holes" in the types are accounted for by adding open type holders to the generated structures. These open type holders consist of a Java Asn1OpenType object reference for storing information on an encoded message fragment for processing at the next level.

ASN1C compiler support for these types of specifications is limited to the correct application of reference types in places where Information Object Class references are embedded in standard ASN.1 types. Other applications of these constructs are parsed but do not result in the generation of any application code.

To better understand the support in this area, the individual components of Information Object specifications are examined. We begin with the "CLASS" specification that provides a schema for Information Object definitions. A sample class specification is as follows:

	OPERATION ::= CLASS {
 
	   &operationCode 		CHOICE { local  INTEGER, 
 
                                		global OBJECT IDENTIFIER }
 
   	   &ArgumentType,
 
    	   &ResultType,
 
   	   &Errors			ERROR		OPTIONAL
 
	}
 

Users familiar with ASN.1 will recognize this as a simplified definition of the ROSE OPERATION MACRO using the Information Object format. When a class specification such as this is parsed, information on its fields is maintained in memory for later reference. The class definition itself does not result in the generation of any corresponding Java code. It is only an abstract template that will be used to define new items later on in the specification.

Fields from within the class can be referenced in standard ASN.1 types. It is these types of references that the compiler is mainly concerned with. These are typically "header" types that are used to add a common header to a variety of other message body types. An example would be the following ASN.1 type definition for a ROSE invoke message header:

	Invoke ::= SEQUENCE {
 
	   invokeID		INTEGER,
 
	   opcode		OPERATION.&operationCode,
 
	   argument		OPERATION.&ArgumentType
 
	}
 

This is a very simple case which purposely omits a lot of additional information such as Information Object Set constraints that are typically a part of definitions such as this. The reason this information is not present is because we are just interested in showing the items that the compiler is concerned with.

The opcode field within this definition is an example of a fixed type field reference It is known as this because if you go back to the original class specification, you will see that operationCode is defined to be of a specific type (namely a choice between a local and global value). The generated Java class for this field will contain a reference to the type from the ASN.1 class definition.

The argument field is an example of a variable type field. In this case, if you refer back to the class definition, you will see that no type is provided. This means that this field can contain an instance of any encoded type (note: in practice, table constraints can be used with Information Object Sets to limit the message types that can be placed in this field). The generated Java class for this field contains an "open type" (Asn1OpenType) reference to hold a previously encoded component to be specified in the final message.

The following would be the procedure to add the Invoke header type to an ASN.1 message body:

• Encode the body type
• Get the message pointer and length of the encoded body
• Create the Asn1OpenType element in the header class using information from the encoded component.
• Populate the remaining Invoke type fields.
• Encode the Invoke type to produce the final message.

Other constructs can be built using class definitions such as Information Object instances and Information Object Sets. This document will not get into the definition and uses of these items other than to say that the ASN1C compiler will parse and silently ignore them. They provide additional information on how to put messages together, but are not part of the actual types themselves. For this reason, the compiler does not generate any additional code for their use.