Versions Compared

Old Version 1

changes.mady.by.user Jenni Wallin

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

A decoder specifies how data is arriving arrives 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:

Code Block
decoder <name> : <decoder options>;

The decoder options are:

...


OptionDescription

in_map(<map name>)

Specifies what in-maps to use. At least one is required.

block_size(<size>)

Specifies that this is a blocked format with specified block size.

terminated_by(<terminator>)

Specifies the block filler used. This option has no effect if block_size has not been specified.

 


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 tries each in_map in the specified order. The first one, for which the identification criteria are met, will be is 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.

...


Info
titleExample - Simple decoder


Code Block
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 jumps to the next even boundary of 2048 and repeat repeats this procedure. If it is not 0x00, it will evaluate evaluates 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.


 

Info
titleExample - Constructed decoder


Code Block
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 switches 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 it means that the Dudr decoder must support identification logic, or the Dtrailer decoder will is never be reached (and the decoder will abort aborts with an "Unexpected EOF" error).

This example could also have been supported with a simple decoder:


 

Info
titleExample - Simple decoder


Code Block
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 does not work if, for instance, the header does not support identification.


 

Scroll pagebreak