PDU data types are stored in their own CSV files, usually of the
form ModuleName_ProductionName.csv
. There are three main
top-level data types of interest:
SEQUENCE / SEQUENCE OF
SET / SET OF
CHOICE
The list types (SEQUENCE
and SET OF
) are
the same as the unit types. The content is repeated when needed on
multiple rows of the CSV file.
Simple types may be used as top-level data types, but in practice this is rare. Translation in this case proceeds as described in the following sections.
As an example, the following SEQUENCE would be dumped to
MyModule_Type1.csv
:
MyModule DEFINITIONS ::= BEGIN Type1 ::= SEQUENCE { ... } END
If the input file type had two such SEQUENCE
s, the
resulting files would be MyModule_Type1.csv
and
MyModule_Type2.csv
.
When a CHOICE
is used as the top-level data type, the
typename for the CHOICE
is ignored and the files are
generated using the typenames in the CHOICE
. For example,
the following specification would generate the same output as the one
with two top-level SEQUENCE
s named Type1
and
Type2
:
MyModule DEFINITIONS AUTOMATIC TAGS ::= BEGIN Type1 ::= SEQUENCE { ... } Type2 ::= SEQUENCE { ... } PDU ::= CHOICE { t1 Type1, t2 Type2 }
When a SEQUENCE
or SET OF
type is used as
the top level, the underlying unit type is referenced instead. For
example, the following ASN.1 specification would create the file
MyModule_Type1.csv
:
MyModule DEFINITIONS ::= BEGIN Type1 ::= SEQUENCE { ... } PDU ::= SEQUENCE OF Type1 END
In this case, the PDU
type carries no extra information
for outputting the data; the contents of Type1
are
outputted on separate lines.
One of the implications of this kind of translation is that the
message structure cannot be reconstructed from the output data files. A
top-level data type of a CHOICE
, SEQUENCE
, or
SEQUENCE OF
may result in exactly the same output
files, even though the bytes of the message may differ. Such ambiguity
should not cause any problems since a specification is required for
decoding the ASN.1 data.