Open Type

[Note] Note

The X.680 Open Type replaces the X.208 ANY or ANY DEFINED BY constructs. An ANY or ANY DEFINED BY encountered within an ASN.1 module will result in the generation of code corresponding to the Open Type described below.

An Open Type as defined in the X.680 standard is specified as a reference to a Type Field in an Information Object Class. The most common form of this is when the Type field in the built-in TYPE-IDENTIFIER class is referenced as follows:

   TYPE-IDENTIFIER.&Type

See the section in this document on Information Objects for a more detailed explanation.

The Open Type is converted into a C or C++ structure used to model a dynamic OCTET STRING type. This structure contains a pointer and length field. The pointer is assumed to point at a string of previously encoded ASN.1 data. When a message containing an open type is decoded, the address of the open type contents field is stored in the pointer field and the length of the component is stored in the length field.

The general mapping of an Open Type to C/C++ is as follows:

ASN.1 production:

   <name> ::= ANY

Generated C code:

   typedef ASN1OpenType <name>;

Generated C++ code:

   typedef ASN1TOpenType <name>;

The difference between the two types is the C++ version contains constructors to initialize the value to zero or to a given open type value.

If the -tables command line option is selected and the ASN.1 type definition references a table constraint, the code generated is different. In this case, ASN1OpenType above is replaced with ASN1Object (or ASN1TObject for C++). This is defined in asn1type.h as follows:

   typedef struct { /* generic table constraint value holder */
      ASN1OpenType encoded;
      void*        decoded;
      OSINT32      index;     /* table index */
   } ASN1Object;

This allows a value of any ASN.1 type to be represented in both encoded and decoded forms. Encoded form is the open type form shown above. It is simply a pointer to a byte buffer and a count of the number of byes in the encoded message component. The decoded form is a pointer to a variable of a specific type. The pointer is void because there could be a potentially large number of different types that can be represented in the table constraint used to constrain a type field to a given set of values. The index member of the type is for internal use by table constraint processing functions to keep track of which row in a table is being referenced.

If the -table-unions command line option is used, a more specialized type of structure is generated. In this case, instead of a void pointer being used to hold an instance of a type containing data to be encoded, all entries from the referenced Information Object Set are used in a union structure in much the same way as is done in a CHOICE construct.

If code is being generated from an XML schema file and the file contains an <xsd:any> wildcard declaration, a special type of any structure is inserted into the generated C/C++ code. This is the type OSXSDAny which is defined in the osSysTypes.h header file. This structure contains a union which contains alternatives for data in either binary or XML text form. This makes it possible to transfer data in either binary form if working with binary encoding rules or XML form if working with XML.