The PXGF format puts data into chunks. Different types of chunks are defined to store different information. The type of a chunk is specified by an int32 field in the chunk as shown in table 3.1. An application that requires data from a particular chunk will register to receive data from that type of chunk. Chunks that are not recognized are simply skipped over. The size field in the chunk allows unrecognized chunks to be skipped over. Each chunk starts with the sync number 0xa1b2c3d4.
|
Element |
Type |
Description |
|
Sync |
int32 |
Synchronization number 0xa1b2c3d4. |
|
Type |
int32 |
Derived from the chunk name, e.g., "SOFH", " EOFH", "SSIQ". |
|
Size |
int32 |
The number of data bytes in the remainder of the chunk The value of size must be a multiple of 4. |
|
Data |
byte[size] |
The chunk data in a format specific to the type. |
Ø The maximum amount of data in a chunk is limited to 65536 bytes. This limits the separation between sync patterns.
Ø The length of each chunk must contain an integral number of 32 bit words even though the size element in the chunk header is specified as a number of bytes.
Ø The PXGF format supports both little and big endian byte ordering, although it may be necessary to provide the stream reader with the endian used depending on its implementation. The endian format for a file or stream may be determined by reading the sync pattern. It is not permissible to mix chunks of different endian format within a stream or file.
Ø When the PXGF format is used to store information in a file, there must be a global header at the beginning of the file to aid identification of the file format and the data stored in the file. This is necessary due to the potentially large size of files.
Ø Nested sub-chunks are not supported as this would unnecessarily complicate synchronization.
Ø The implication of the previous point is that all chunks are at root level and are interpreted entirely sequentially. The parser must know which chunks need to be identified before it can use other chunks. The only constraint here is that files must start with a “SOFH chunk”. Due to the sequential nature of parsing and the inability to nest chunks, a separate global chunk is needed to identify the end of the file header, namely the “EOFH” chunk.