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.
The ASN.1 Open Type is converted into a Java class that extends the Asn1OpenType class. This class in turn extends the Asn1OctetString class and provides the following public member variable for storing the encoded message component:
public byte[] value;
The number of octets to be encoded or that were decoded is specified in the built-in length component of the array object (i.e., value.length).
The following shows the basic mapping from ASN.1 type to Java class definition:
ASN.1 Production
<name> ::= <openType>
Generated Java class
public class <name> extends Asn1OpenType { public <name> () { super(); } public <name> (byte[] data) { super (data); } public <name> (byte[] data, int offset, int nbytes) { super (data, offset, nbytes); } public <name> (Asn1EncodeBuffer buffer) { super (); } }
The <openType> placeholder is to be replaced with any type of open type specification. It could be the ANY or ANY DEFINED BY keywords from the X.208 specification or an open type from X.681 (for example, TYPEIDENTIFIER.& Type).
The last form of the constructor shown above is for an optimized form of Open Type encoding. When encoding is done using BER, an open type header can be directly added to the beginning of an encoded message component. By using this form of the constructor, you are indicating to the run-time encoder that the encoded message component onto which a header is to be added is already present in the message buffer. The advantage is that binary copies of the encoded message components are avoided both from the encode buffer to the open type object and from the open type object back to the encode buffer.
For XER, a new class derived from the Asn1OpenType class was created. This is the Asn1XerOpenType class and this must be used whenever an open type is required for XER. The reason for creating a special derived class is because of dependencies on XML parser classes defined within this class. If these were added directly to the Asn1OpenType class, a user would need to always have XML parser .jar files included in their classpath – even if working with BER, DER, or PER only.
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 Asn1Type. This the base class for all ASN.1 types. This allows a value of any ASN.1 type to be specified. On the encoding side, a user can assign an object of any ASN.1 type to this variable and the encoding routine will call the appropriate encoder according to the table index value. If the variable type is not present in the table and the Object Set is extensible, than it can be encoded as an open type. Otherwise an exception will be thrown. On the decoding side, the appropriate variable type is populated from the table based on the decoded index parameters. The user can determine the variable type from the table index value. If the variable type is not present in table, then it will be decoded as an open type if the Object Set is extensible; otherwise and exception will be thrown.
<xsd:any> Handling
The XSD any wildcard item is similar to an ASN.1 open type in semantics in that it allows any valid content to be present in that position in an XML document. However, an ASN.1 open type is not used to model an <xsd:any>. Instead, a character string variable is used. This stores the full XML text of the field in native XML form (i.e. angle brackets and the like are not escaped). Note that the XML text is not converted to different form when using binary encoding rules - it is maintained as XML text.