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
For all intents and purposes, 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.