A decoder specifies how data is arriving from a source. There are two basic types of decoders:
Simple decoders - Decode one or more external formats.
Constructed decoders - Coordinate the decoding between multiple simple or constructed decoders.
Simple Decoders
The syntax of a simple decoder is declared as follows:
decoder <name> : <decoder options>;
The decoder options are:
| Option | Description |
|---|---|
| Specifies what in-maps to use. At least one is required. |
| Specifies that this is a blocked format with specified block size. |
| Specifies the block filler used. This option has no effect if |
The decoder may contain one or several in-maps, depending on whether it manages a single or multiple (mixed) record type. For multiple maps, the corresponding external records except the last one must support identification. The decoder will try each in_map in the specified order. The first one, for which the identification criteria are met, will be used.
How the record identification is specified depends on the actual external record type. For example, sequential external records must use the identified_byoption while BER encoded records support identification by the standard tagging scheme.
Simple decoders may be given blocking information through the block_size and terminated_by constructs. The block_size parameter contains the size of a block and the terminated_by parameter specifies the start of a padding character.
Example - Simple decoder
decoder SimpleDecoder : in_map(Map1), in_map(Map2),
block_size(2048), terminated_by(0x00);
This decoder starts by reading the next byte and evaluates if it equals 0x00. Should it be 0x00, it will jump to the next even boundary of 2048 and repeat this procedure. If it is not 0x00, it will evaluate the identification for both of the externals specified in Map1 and Map2 (in that order).
Constructed Decoders
A constructed decoder is defined in terms of a number of other simple or constructed decoders. They are used to specify the decoders to be used in sequence, for example to specify separate decoders managing header, trailer, and record information. For instance, three external record types (Rheader, Rudr, Rtrailer), with corresponding in_maps (Mheader, Mudr, and Mtrailer) and decoders (Dheader, Dudr, and Dtrailer).
The following constructed decoder specifies the header record to be decoded first. Then any number of UDR records are decoded, followed by a single trailer record.
Example - Constructed decoder
decoder TTFile {
decoder Dheader;
decoder Dudr *;
decoder Dtrailer;
};
As can be seen, the constructed decoder does not (and cannot) have any decoder options.
The asterisk after Dudr indicates that zero or more entries can occur before a terminating trailer record. For such a sub-decoder, the constructed decoder will switch to the next decoder when the sub-decoder cannot handle the input (as deduced by the identification criteria of the in_maps in the sub-decoder). In this case this means that the Dudr decoder must support identification logic, or the Dtrailer decoder will never be reached (and the decoder will abort with an "Unexpected EOF" error).
This example could also have been supported with a simple decoder:
Example - Simple decoder
decoder TTFile :
in_map(Mheader), in_map(Mudr), in_map(Mtrailer);
The difference is that the order of header, UDR, and trailer would not be enforced for the simple decoder. The simple decoder will also not work if, for instance, the header does not support identification.