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:

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 SEQUENCEs, 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 SEQUENCEs 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.