ISO/IEC 18023-3 — Transmittal format binary encoding
The abstract transmittal format (ATF) is the standard interchange mechanism for SEDRIS transmittals as defined in ISO/IEC 18023-2 (see 2.[I18023-2]). The ATF is realized by specifying an encoding that maps the elements of the ATF into specific elements in one or more files. This part of ISO/IEC 18023 defines a binary encoding that conforms to the ATF. The name of this binary encoding is SEDRIS Transmittal Format (STF).
See Table 4.1 for the table of contents for this clause.
|
4.1 Introduction and table of contents 4.3.2 STF-encoded SEDRIS transmittal root file 4.3.3.1 STF Object File structure 4.3.3.3 Object data and object referencing 4.3.4.2 Data table data storage |
The binary encoding of the SEDRIS transmittal format (STF) provides an efficient platform independent interchange mechanism for SEDRIS transmittals. The STF is a file format that defines the syntax of a binary-encoded SEDRIS transmittal.
A SEDRIS transmittal encoded using the techniques defined in this part of ISO/IEC 18023 consists of a set of files that together are termed an STF-encoded SEDRIS transmittal. An STF-encoded SEDRIS transmittal shall contain:
Each of these is described below.
An STF-encoded SEDRIS transmittal root file contains information that pertains to the entire transmittal and also information used to implement inter-transmittal reference (ITR) and non-ITR object references. It has the general structure shown in Figure 4.1:
|
Master file table |
|
ITR referenced transmittal table |
|
ITR referenced object table |
|
Published object table |
4.1 — STF Root File structure
The Root File Header contains transmittal level information and fields to validate and identify the STF format and version of the transmittal.
The Master File Table lists all of the data files that comprise this transmittal.
ITR Referenced Transmittal Table is a list of the names of all transmittals referenced from this Transmittal.
ITR Referenced Object Table contains an entry for every ITR reference within this transmittal. Each entry identifies the transmittal and published name of the object being referenced.
Published Object Table is a list of objects in the transmittal that may be referenced from other transmittals.
The exact form for each element in the STF Root File is specified in 6 Transmittal content representation.
The STF Object Files contain all of the DRM objects in the transmittal including field data and relationships. Each STF Object File has the structure show in Figure 4.2:
Figure 4.2 — STF Object File structure
The File Header contains fields to validate the STF format and identify the version of the data. It also contains organizational information.
Following the File Header are from one to 4096 STF Blocks as described in 4.4.3.2 STF Block.
The Referenced File Table is a list of the STF Object Files and STF ImgDTData files that contain an object that is referenced from an object within this file.
The Block Table data consists of two tables containing information on the sizes, location and compression of each STF Block in the file.
Each STF Object File contains up to 4096 STF Blocks. Each block is then used to store and organize up to 256 STF Objects which represent DRM Objects in the transmittal. Each STF Object is given an index from 0 to 255 to locate it within the block. The layout of the block is depicted in Figure 4.3:
Figure 4.3 — STF Block layout
Block Header specifies the number of objects in the block and the location of the object pointer table in the block.
The Object Type Table specifies the DRM class of each object in the block.
Object Data contains object-specific data for each object as described in 4.3.3.3 Object data and object referencing.
The Object Pointer Table specifies the location of each object in the block. It also indicates which objects have been deleted from the transmittal.
STF Object data consists of the association, component, and aggregation relationships for the object as well as any DRM field data. The format of the DRM fields is defined in 6.3 DRM object representation. The relationship information is implemented by storing lists of object references. Since the aggregation (parent to child) relationship is always a two-way relationship, STF stores each object’s parents and children separately. The parents are stored as aggregate object references, the children as component object references and the associated objects as associate object references.
In order to implement these object references, STF uniquely identifies every object in the transmittal. STF uses a set of three zero-based indices for this purpose. Every object has a reference called an FBO that is comprised of a File Index (F), a Block Index (B), and an Object Index (O). The File Index is the index into the STF Root File’s Master File Table. This table specifies in which file the object is located. The Block Index is the index into the file’s Block Table that specifies in which block the object is located within the file identified by F. The Object Index identifies the specific object within the block identified by B.
The encoding of an FBO shall be as described in 5.2.4.2 STF_FBO.
DRM_Image and DRM_Data_Table objects have non-field data associated with the object. Such data is stored in the ImgDTData Files.
The ImgDTData Files are structurally identical to the STF Object Files with the exception of the object data for the individual objects. An ImgDTData file has a File Header, Reference File Table and Block Table of the same format as the STF Object File (see 4.4.3 STFObjectFile). The format of the Block Header, Object Type Table and Object Pointer Table is also the same. However, the object types are limited to one of only four types of objects:
The format of these objects is defined in 6.4 STF-specific constructs.
These image and data table objects also use the same FBO object referencing mechanism. A component object references from a DRM_Image object to a IMAGE_DATA object is used to locate the image data for the DRM_Image. DRM_Data_Table objects have component object references to DT_DATA objects. While STF considers these components, they do not represent component relationships as defined in the DRM.
A DRM_Data_Table is an n-dimensional table of cells. Each cell may contain any number of elements. The number, size and extents of the cells of a DRM_Data_Table are defined by its ordered set of DRM_Axis components. The number, meaning, and data type of each of the elements of a cell are defined by the ordered DRM_Table_Property_Description components of the DRM_Data_Table. Detailed information about data tables may be found in 2.[I18023-1].
One DT_DATA object exists for each element in the data table. The DT_DATA object serves to organize the storage of the data values for the element. The data is stored in DT_BLOCK_DATA objects as components of the DT_DATA objects. A DT_BLOCK_PARAM object is referenced as a link to this component relationship. The DT_BLOCK_PARAM object stores information about the type, extents, and storage parameters of the data contained in the DT_BLOCK_DATA object.
Each DT_DATA_BLOCK contains data for a given subextent of the data table. There is no set value on the number or size of the blocks or on the subextents partitioning the data. A DT_BLOCK_PARAM object defines the subextents and the number of cells for the corresponding DT_BLOCK_DATA object. For an n-dimensional data table, every DT_BLOCK_DATA object will have an n-dimensional subextents. This set of subextents shall completely partition the extents of the data table so that every element in the data table is in one and only one DT_BLOCK_DATA’s subextents.
The DT_BLOCK_DATA stores an n-dimensional array of values termed block_data_values. The format of the block_data_values is discussed in 4.4.4.2.3 Block Data format and packing. The size of each dimension in this array is determined from the first_index and last_index values of the subextent’s corresponding dimension.
This technique is illustrated in Figure 4.4:
Figure 4.4 — Three-dimensional data table example
This data table instance has been partitioned into four data blocks with the subextents shown in Table 4.2:
Table 4.2 — Three-dimensional data table example subextents
|
|
Axis 0 |
Axis 1 |
Axis 2 |
block_data_value array |
|---|---|---|---|---|
|
Block 0 |
0,39 |
0,24 |
0,29 |
(40,25,30) |
|
Block 1 |
40,79 |
0,24 |
0,29 |
(40,25,30) |
|
Block 2 |
0,39 |
25,49 |
0,29 |
(40,25,30) |
|
Block 3 |
40,79 |
25,49 |
0,29 |
(40,25,30) |
The block_data_values in the n-dimesional array are sequenced such that the values along the last axis are stored in order, followed by the values of the penultimate axis continuing until the values of the first axis have been stored.
For the three-dimensional table example above, the ith element in the sequence is specified by:
(x × 30 × 25) + (y × 30) + z
where (x,y,z) is the coordinate of the block_data_value in the three-dimesional array.
The data values within the DT_BLOCK_DATA may be packed or not packed. If not packed, the block_data_values represent the actual element values and are encoded based on their data type. Encoding of data types is specified in Clause 5.
For integer and float data types, the block_data_values may be packed. In this case, the values are encoded as bit fields representing unsigned numbers. The size of the bit field will vary from block to block depending on the data type and the values in the block. The bit fields are encoded one after another with no padding and without respect to any word boundaries. This is shown Figure 4.5 for four block_data_values with a bit field size of five represented by aaaaa, bbbbb, ccccc, and ddddd:
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
a |
a |
a |
a |
a |
b |
b |
b |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
b |
b |
c |
c |
c |
c |
c |
d |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
d |
d |
d |
d |
• • • |
|||
Figure 4.5 — Block_data_value five-bit fields
When packed, the block_data_value does not represent the element value directly but instead is used to calculate the element value using a base (minimum) value, a scale factor, and for float types, a tolerance value. The minimum value, scale factor, and tolerance are stored in the DT_BLOCK_PARAM object. In addition, it is possible to have up to five block_data_value sentinels that are used to represent metadata sentinel values as specified by the DRM_Property_Characteristic components of the DRM_Table_Property_Description objects. The DT_BLOCK_PARAM object contains a mapping from each block_data_value sentinel to its corresponding element value which the user will interpret as a sentinel.
For integer types, the block_data_value is first compared to the list of sentinels and, if found, Element_Value is set to the mapped element value. If not found, Element_Value is computed as follows:
Element_Value = (block_data_value × 2scale_factor) + base_data_value
For floating point types, the block_data_value is first compared to the list of sentinels and, if not found, Element_Value is computed as follows:
Element_Value = (block_data_value × 2scale_factor) × tolerance + base_data_value