
/** \page FMT1 HDF5 File Format Specification Version 1.0

Navigate back: \ref index "Main" / \ref SPEC
<hr>

<table align="right">
<tr><td>
    <ol type="I">
      <li> @ref sec_fmt1_intro</li>
      <li> @ref sec_fmt1_boot</li>
      <li> @ref sec_fmt1_group
          <ol type="A">
          <li> @ref subsec_fmt1_group_btrees</li>
          <li> @ref subsec_fmt1_group_symboltable</li>
          <li> @ref subsec_fmt1_group_symboltableentry</li>
          <li> @ref subsec_fmt1_group_localheap</li>
          <li> @ref subsec_fmt1_group_globalheap</li>
          <li> @ref subsec_fmt1_group_freespaceindex</li>
        </ol></li>
      <li> @ref sec_fmt1_dataobject
        <ol type="A">
          <li> @ref subsec_fmt1_dataobject_hdr
            <ol type="1">
              <li> @ref subsubsec_fmt1_dataobject_hdr_nil</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_simple</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_dtmessage</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_fvmessage</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_message_0005</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_compact</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_external</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_layout</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_message_0009</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_message_000A</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_filter</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_attribute</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_name</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_modified</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_shared</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_continuation</li>
              <li> @ref subsubsec_fmt1_dataobject_hdr_stmgroup</li>
            </ol></li>
          <li> @ref subsec_fmt1_dataobject_sharedhdr</li>
          <li> @ref subsec_fmt1_dataobject_storage</li>
        </ol>
      </li>
    </ol>
</td></tr>
</table>

\section sec_fmt1_intro Introduction

<table align="right">
<tr>
<td><strong>Figure 1:</strong> Relationships among the HDF5 root group, other groups, and objects</td>
</tr>
<tr>
<td>\image html FF-IH_FileGroup.gif</td>
</tr>
<tr>
<td><strong>Figure 2:</strong> HDF5 objects -- datasets, datatypes, or dataspaces</td>
</tr>
<tr>
<td>\image html FF-IH_FileObject.gif</td>
</tr>
</table>

The format of an HDF5 file on disk encompasses several key ideas of the HDF4 and AIO file formats as well
as addressing some shortcomings therein. The new format is more self-describing than the HDF4 format and
is more uniformly applied to data objects in the file.

An HDF5 file appears to the user as a directed graph. The nodes of this graph are the higher-level HDF5
objects that are exposed by the HDF5 APIs:
\li Groups
\li Datasets
\li Datatypes
\li Dataspaces

At the lowest level, as information is actually written to the disk, an HDF5 file is made up of the
following objects:
\li A super block
\li B-tree nodes (containing either symbol nodes or raw data chunks)
\li Object headers
\li Collections
\li Local heaps
\li Free space

The HDF5 library uses these lower-level objects to represent the higher-level objects that are then
presented to the user or to applications through the APIs. For instance, a group is an object header that
contains a message that points to a local heap and to a B-tree which points to symbol nodes. A dataset is
an object header that contains messages that describe datatype, space, layout, filters, external files,
fill value, etc with the layout message pointing to either a raw data chunk or to a B-tree that points to
raw data chunks.

\subsection subsec_fmt1_intro_doc This Document
This document describes the lower-level data objects; the higher-level objects and their properties are
described in the \ref UG.

Three levels of information comprise the file format. Level 0 contains basic information for identifying
and defining information about the file. Level 1 information contains the group information (stored as
a B-tree) and is used as the index for all the objects in the file. Level 2 is the rest of the file and
contains all of the data objects, with each object partitioned into header information, also known as
<em>meta information</em>, and data.

The sizes of various fields in the following layout tables are determined by looking at the number of
columns the field spans in the table. There are three exceptions: (1) The size may be overridden by
specifying a size in parentheses, (2) the size of addresses is determined by the <em>Size of Offsets</em>
field in the super block, and (3) the size of size fields is determined by the <em>Size of Lengths</em>
field in the super block.

\section sec_fmt1_boot Disk Format: Level 0 - File Signature and Super Block
The super block may begin at certain predefined offsets within the HDF5 file, allowing a block of
unspecified content for users to place additional information at the beginning (and end) of the HDF5 file
without limiting the HDF5 library's ability to manage the objects within the file itself. This feature was
designed to accommodate wrapping an HDF5 file in another file format or adding descriptive information to
the file without requiring the modification of the actual file's information. The super block is located by
searching for the HDF5 file signature at byte offset 0, byte offset 512 and at successive locations in the
file, each a multiple of two of the previous location, i.e. 0, 512, 1024, 2048, etc.

The super block is composed of a file signature, followed by super block and group version numbers,
information about the sizes of offset and length values used to describe items within the file, the size of
each group page, and a group entry for the root object in the file.

<table>
<caption align="top"><strong>HDF5 Super Block Layout</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4><br />HDF5 File Signature (8 bytes)<br /><br /></td>
</tr>
<tr align=center>
  <td>Version \# of Super Block</td>
  <td>Version \# of Global Free-space Storage</td>
  <td>Version \# of Group</td>
  <td>Reserved</td>
</tr>
<tr align=center>
  <td>Version \# of Shared Header Message Format</td>
  <td>Size of Offsets</td>
  <td>Size of Lengths</td>
  <td>Reserved (zero)</td>
</tr>
<tr align=center>
  <td colspan=2>Group Leaf Node K</td>
  <td colspan=2>Group Internal Node K</td>
</tr>
<tr align=center>
  <td colspan=4>File Consistency Flags</td>
</tr>
<tr align=center>
  <td colspan=4>Base Address*</td>
</tr>
<tr align=center>
  <td colspan=4>Address of Global Free-space Heap*</td>
</tr>
<tr align=center>
  <td colspan=4>End of File Address*</td>
</tr>
<tr align=center>
  <td colspan=4>Driver Information Block Address*</td>
</tr>
<tr align=center>
  <td colspan=4>Root Group Address*</td>
</tr>
</table>
\li Items marked with an asterisk (*) in the above table are of the size specified in "Size of Offsets."

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>File Signature</td>
  <td>This field contains a constant value and can be used to quickly identify a file as being an HDF5
      file. The constant value is designed to allow easy identification of an HDF5 file and to allow
      certain types of data corruption to be detected. The file signature of an HDF5 file always
      contains the following values:
    <br /><br /><center>
    <table align=center cellpadding=4 width="100%">
    <tr align=center>
      <td>decimal</td>
      <td width="8%">137</td>
      <td width="8%">72</td>
      <td width="8%">68</td>
      <td width="8%">70</td>
      <td width="8%">13</td>
      <td width="8%">10</td>
      <td width="8%">26</td>
      <td width="8%">10</td>
    </tr>
    <tr align=center>
      <td>hexadecimal</td>
      <td width="8%">89</td>
      <td width="8%">48</td>
      <td width="8%">44</td>
      <td width="8%">46</td>
      <td width="8%">0d</td>
      <td width="8%">0a</td>
      <td width="8%">1a</td>
      <td width="8%">0a</td>
    </tr>
    <tr align=center>
      <td>ASCII C Notation</td>
      <td width="8%">\211</td>
      <td width="8%">H</td>
      <td width="8%">D</td>
      <td width="8%">F</td>
      <td width="8%">\\r</td>
      <td width="8%">\\n</td>
      <td width="8%">\032</td>
      <td width="8%">\\n</td>
    </tr>
    </table></center>
    <br />
    This signature both identifies the file as an HDF5 file and provides for immediate detection of common
    file-transfer problems. The first two bytes distinguish HDF5 files on systems that expect the first two
    bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the
    probability that a text file may be misrecognized as an HDF5 file; also, it catches bad file transfers
    that clear bit 7. Bytes two through four name the format. The CR-LF sequence catches bad file transfers
    that alter newline sequences. The control-Z character stops file display under MS-DOS. The final line
    feed checks for the inverse of the CR-LF translation problem. (This is a direct descendent of the PNG
    file signature.)</td>
</tr>
<tr valign=top>
  <td>Version Number of the Super Block</td>
  <td>This value is used to determine the format of the information in the super block. When the format of
      the information in the super block is changed, the version number is incremented to the next integer
      and can be used to determine how the information in the super block is formatted.</td>
</tr>
<tr valign=top>
  <td>Version Number of the Global Free-space Heap</td>
  <td>This value is used to determine the format of the information in the Global Free-space Heap.</td>
</tr>
<tr valign=top>
  <td>Version Number of the Group</td>
  <td>This value is used to determine the format of the information in the Group. When the format of the
      information in the Group is changed, the version number is incremented to the next integer and can be
      used to determine how the information in the Group is formatted.</td>
</tr>
<tr valign=top>
  <td>Version Number of the Shared Header Message Format</td>
  <td>This value is used to determine the format of the information in a shared object header message, which
      is stored in the global small-data heap. Since the format of the shared header messages differs from
      the private header messages, a version number is used to identify changes in the format.</td>
</tr>
<tr valign=top>
  <td>Size of Offsets</td>
  <td>This value contains the number of bytes used to store addresses in the file. The values for the
      addresses of objects in the file are offsets relative to a base address, usually the address of the
      super block signature. This allows a wrapper to be added after the file is created without invalidating
      the internal offset locations.</td>
</tr>
<tr valign=top>
  <td>Size of Lengths</td>
  <td>This value contains the number of bytes used to store the size of an object.</td>
</tr>
<tr valign=top>
  <td>Group Leaf Node K</td>
  <td>Each leaf node of a group B-tree will have at least this many entries but not more than twice this
      many. If a group has a single leaf node then it may have fewer entries.</td>
</tr>
<tr valign=top>
  <td>Group Internal Node K</td>
  <td>Each internal node of a group B-tree will have at least K pointers to other nodes but not more than 2K
      pointers. If the group has only one internal node then it might have fewer than K pointers.</td>
</tr>
<tr valign=top>
  <td>Bytes per B-tree Page</td>
  <td>This value contains the number of bytes used for symbol pairs per page of the B-trees used in the file.
      All B-tree pages will have the same size per page. <br />
      For 32-bit file offsets, 340 objects is the maximum per 4KB page; for 64-bit file offset, 254 objects
      will fit per 4KB page. In general, the equation is: <br />
      <code>&nbsp;&nbsp;&nbsp;&lt;<i>number of objects</i>&gt; = <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      FLOOR((&lt;<i>page size</i>&gt; - &lt;<i>offset size</i>&gt;) /
      <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      (&lt;<i>Symbol size</i>&gt; + &lt;<i>offset size</i>&gt;)) - 1 </code></td>
</tr>
<tr valign=top>
  <td>File Consistency Flags</td>
  <td>This value contains flags to indicate information about the consistency of the information contained
      within the file. Currently, the following bit flags are defined:
      <ul>
        <li>Bit 0 set indicates that the file is opened for write-access.</li>
        <li>Bit 1 set indicates that the file has been verified for consistency and is guaranteed to be
        consistent with the format defined in this document.</li>
        <li>Bits 2-31 are reserved for future use.</li>
      </ul>
      Bit 0 should be set as the first action when a file is opened for write access and should be cleared
      only as the final action when closing a file. Bit 1 should be cleared during normal access to a file
      and only set after the file's consistency is guaranteed by the library or a consistency utility.</td>
</tr>
<tr valign=top>
  <td>Base Address</td>
  <td>This is the absolute file address of the first byte of the HDF5 data within the file. The library
      currently constrains this value to be the absolute file address of the super block itself when creating
      new files; future versions of the library may provide greater flexibility. Unless otherwise noted, all
      other file addresses are relative to this base address.</td>
</tr>
<tr valign=top>
  <td>Address of Global Free-space Heap</td>
  <td>Free-space management is not yet defined in the HDF5 file format and is not handled by the library.
      Currently this field always contains the undefined address <code>0xfff...ff</code>.</td>
</tr>
<tr valign=top>
  <td>End of File Address</td>
  <td>This is the relative file address of the first byte past the end of all HDF5 data. It is used to
      determine whether a file has been accidentally truncated and as an address where file data allocation
      can occur if the free list is not used.</td>
</tr>
<tr valign=top>
  <td>Driver Information Block Address</td>
  <td>This is the relative file address of the file driver information block which contains driver-specific
      information needed to reopen the file. If there is no driver information block then this entry should
      be the undefined address (all bits set).</td>
</tr>
<tr valign=top>
  <td>Root Group Address</td>
  <td>This is the address of the root group (described later in this document), which serves as the entry
      point into the group graph.</td>
</tr>
</table>

The <em>file driver information block</em> is an optional region of the file which contains information
needed by the file driver in order to reopen a file. The format of the file driver information block is:
<table>
<caption align=top><strong>Driver Information Block</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td>Version</td>
  <td colspan=3>Reserved (zero)</td>
</tr>
<tr align=center>
  <td colspan=4>Driver Information Size (4 bytes)</td>
</tr>
<tr align=center>
  <td colspan=4><br />Driver Identification (8 bytes)<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br /><br />Driver Information<br /><br /><br /></td>
</tr>
</table>

<table>
<tr>
 <th width="30%">Field Name</th>
 <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version</td>
  <td>The version number of the driver information block. The file format documented here is version zero.</td>
</tr>
<tr valign=top>
  <td>Driver Information Size</td>
  <td>The size in bytes of the Driver Information part of this structure.</td>
</tr>
<tr valign=top>
  <td>Driver Identification</td>
  <td>This is an eight-byte ASCII string without null termination which identifies the driver and version number
    of the Driver Information block. The predefined drivers supplied with the HDF5 library are identified by the
    letters <code>NCSA</code> followed by the first four characters of the driver name. If the Driver Information
    block is not the original version then the last letter(s) of the identification will be replaced by a version
    number in ASCII. For example, the various versions of the <em>family driver</em> will be identified by
    <code>NCSAfami</code>, <code>NCSAfam0</code>, <code>NCSAfam1</code>, etc. (<code>NCSAfami</code> is simply
    <code>NCSAfamily</code> truncated to eight characters.  Subsequent identifiers will be created by
    substituting sequential numerical values for the final character, starting with zero.) <br />
    Identification for user-defined drivers is arbitrary but should be unique.</td>
</tr>
<tr valign=top>
  <td>Driver Information</td>
  <td>Driver information is stored in a format defined by the file driver and encoded/decoded by the driver
      callbacks invoked from the <code>H5FD_sb_encode</code> and <code>H5FD_sb_decode</code> functions.</td>
</tr>
</table>

\section sec_fmt1_group Disk Format: Level 1 - File Infrastructure

\subsection subsec_fmt1_group_btrees Disk Format: Level 1A - B-link Trees and B-tree Nodes
B-link trees allow flexible storage for objects which tend to grow in ways that cause the object to be stored
discontiguously. B-trees are described in various algorithms books including "Introduction to Algorithms" by
Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest. The B-link tree, in which the sibling nodes at
a particular level in the tree are stored in a doubly-linked list, is described in the "Efficient Locking
for Concurrent Operations on B-trees" paper by Phillip Lehman and S. Bing Yao as published in the <em>ACM
Transactions on Database Systems</em>, Vol. 6, No. 4, December 1981.

The B-link trees implemented by the file format contain one more key than the number of children. In other
words, each child pointer out of a B-tree node has a left key and a right key. The pointers out of internal
nodes point to sub-trees while the pointers out of leaf nodes point to symbol nodes and raw data chunks.
Aside from that difference, internal nodes and leaf nodes are identical.

<table>
<caption align="top"><strong>B-tree Nodes</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Node Signature</td>
</tr>
<tr align=center>
  <td>Node Type</td>
  <td>Node Level</td>
  <td colspan=2>Entries Used</td>
</tr>
<tr align=center>
  <td colspan=4>Address of Left Sibling</td>
<tr align=center>
  <td colspan=4>Address of Right Sibling</td>
</tr>
<tr align=center>
  <td colspan=4>Key 0 (variable size)</td>
</tr>
<tr align=center>
  <td colspan=4>Address of Child 0</td>
<tr align=center>
  <td colspan=4>Key 1 (variable size)</td>
<tr align=center>
  <td colspan=4>Address of Child 1</td>
</tr>
<tr align=center>
  <td colspan=4>...</td>
</tr>
<tr align=center>
  <td colspan=4>Key 2<em>K</em> (variable size)</td>
</tr>
<tr align=center>
  <td colspan=4>Address of Child 2<em>K</em></td>
</tr>
<tr align=center>
  <td colspan=4>Key 2<em>K</em>+1 (variable size)</td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Node Signature</td>
  <td>The ASCII character string <code>TREE</code> is used to indicate the beginning of a B-link tree node.
      This gives file consistency checking utilities a better chance of reconstructing a damaged file.</td>
</tr>
<tr valign=top>
  <td>Node Type</td>
  <td>Each B-link tree points to a particular type of data. This field indicates the type of data as well as
    implying the maximum degree <em>K</em> of the tree and the size of each Key field.<br />
    <dl compact>
      <dt>0</dt>
      <dd>This tree points to group nodes.</dd>
      <dt>1</dt>
      <dd>This tree points to a new data chunk.</dd>
    </dl>
  </td>
</tr>
<tr valign=top>
  <td>Node Level</td>
  <td>The node level indicates the level at which this node appears in the tree (leaf nodes are at level
      zero). Not only does the level indicate whether child pointers point to sub-trees or to data, but it
      can also be used to help file consistency checking utilities reconstruct damaged trees.</td>
</tr>
<tr valign=top>
  <td>Entries Used</td>
  <td>This determines the number of children to which this node points.  All nodes of a particular type of
      tree have the same maximum degree, but most nodes will point to less than that number of children. The
      valid child pointers and keys appear at the beginning of the node and the unused pointers and keys
      appear at the end of the node. The unused pointers and keys have undefined values.</td>
</tr>
<tr valign=top>
  <td>Address of Left Sibling</td>
  <td>This is the file address of the left sibling of the current node relative to the super block. If the
      current node is the left-most node at this level then this field is the undefined address (all bits
      set).</td>
</tr>
<tr valign=top>
  <td>Address of Right Sibling</td>
  <td>This is the file address of the right sibling of the current node relative to the super block. If the
      current node is the right-most node at this level then this field is the undefined address (all bits
      set).</td>
</tr>
<tr valign=top>
  <td>Keys and Child Pointers</td>
  <td>Each tree has 2<em>K</em>+1 keys with 2<em>K</em> child pointers interleaved between the keys. The number
      of keys and child pointers actually containing valid values is determined by the <em>Entries Used</em>
      field. If that field is <em>N</em> then the B-link tree contains <em>N</em> child pointers and
      <em>N</em>+1 keys.</td>
</tr>
<tr valign=top>
  <td>Key</td>
  <td>The format and size of the key values is determined by the type of data to which this tree points. The
      keys are ordered and are boundaries for the contents of the child pointer; that is, the key values
      represented by child <em>N</em> fall between Key <em>N</em> and Key <em>N</em>+1. Whether the interval
      is open or closed on each end is determined by the type of data to which the tree points.<br />
      The format of the key depends on the node type. For nodes of node type 1, the key is formatted as follows:
      <table>
      <tr valign=top align=left>
        <td width=40%>Bytes 1-4</td>
        <td>Size of chunk in bytes.</td>
      </tr>
      <tr valign=top align=left>
        <td>Bytes 4-8</td>
        <td>Filter mask, a 32-bit bitfield indicating which filters have been applied to that chunk.</td>
      </tr>
      <tr valign=top align=left>
        <td><i>N</i> fields of 8 bytes each</td>
        <td>A 64-bit index indicating the offset of the chunk within the dataset where <i>N</i> is the number
            of dimensions of the dataset. For example, if a chunk in a 3-dimensional dataset begins at the
            position <code>[5,5,5]</code>, there will be three such 8-bit indices, each with the value of
            <code>5</code>.</td>
      </tr>
      </table>
      <br />
      For nodes of node type 0, the key is formatted as follows:
      <table>
      <tr valign=top align=left>
        <td width=40%>A single field of <i>Size of Lengths</i> bytes</td>
        <td>Indicates the byte offset into the local heap for the first object name in the subtree which
            that key describes.</td>
      </tr>
      </table>
    </td>
</tr>
<tr valign=top>
  <td>Child Pointers</td>
  <td>The tree node contains file addresses of subtrees or data depending on the node level. Nodes at Level
      0 point to data addresses, either data chunk or group nodes. Nodes at non-zero levels point to other
      nodes of the same B-tree.</td>
</tr>
</table>

Each B-tree node looks like this:
<table>
<tr valign=top align=center>
  <td>key[0]</td><td>&nbsp;&nbsp;</td>
  <td>child[0]</td><td>&nbsp;&nbsp;</td>
  <td>key[1]</td><td>&nbsp;&nbsp;</td>
  <td>child[1]</td><td>&nbsp;&nbsp;</td>
  <td>key[2]</td><td>&nbsp;&nbsp;</td>
  <td>...</td><td>&nbsp;&nbsp;</td>
  <td>...</td><td>&nbsp;&nbsp;</td>
  <td>key[<i>N</i>-1]</td><td>&nbsp;&nbsp;</td>
  <td>child[<i>N</i>-1]</td><td>&nbsp;&nbsp;</td>
  <td>key[<i>N</i>]</td>
</tr>
</table>
where child[<i>i</i>] is a pointer to a sub-tree (at a level above Level 0) or to data (at Level 0).
Each key[<i>i</i>] describes an <i>item</i> stored by the B-tree (a chunk or an object of a group node).
The range of values represented by child[<i>i</i>] are indicated by key[<i>i</i>] and key[<i>i</i>+1].

The following question must next be answered: &ldquo;Is the value described by key[<i>i</i>] contained in
child[<i>i</i>-1] or in child[<i>i</i>]?&rdquo; The answer depends on the type of tree. In trees for groups (node
type 0) the object described by key[<i>i</i>] is the greatest object contained in child[<i>i</i>-1] while
in chunk trees (node type 1) the chunk described by key[<i>i</i>] is the least chunk in child[<i>i</i>].

That means that key[0] for group trees is sometimes unused; it points to offset zero in the heap, which is
always the empty string and compares as "less-than" any valid object name.

And key[<i>N</i>] for chunk trees is sometimes unused; it contains a chunk offset which compares as
"greater-than" any other chunk offset and has a chunk byte size of zero to indicate that it is not actually
allocated.

\subsection subsec_fmt1_group_symboltable Disk Format: Level 1B - Group and Symbol Nodes
A group is an object internal to the file that allows arbitrary nesting of objects (including other groups).
A group maps a set of names to a set of file address relative to the base address. Certain meta data for an
object to which the group points can be duplicated in the group symbol table in addition to the object header.

An HDF5 object name space can be stored hierarchically by partitioning the name into components and storing
each component in a group. The group entry for a non-ultimate component points to the group containing the
next component. The group entry for the last component points to the object being named.

A group is a collection of group nodes pointed to by a B-link tree. Each group node contains entries for one
or more symbols. If an attempt is made to add a symbol to an already full group node containing 2<em>K</em>
entries, then the node is split and one node contains <em>K</em> symbols and the other contains <em>K</em>+1
symbols.

<table>
<caption align="top"><strong>Group Node (A Leaf of a B-tree)</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Node Signature</td>
</tr>
<tr align=center>
  <td>Version Number</td>
  <td>Reserved for Future Use</td>
  <td colspan=2>Number of Symbols</td>
</tr>
<tr align=center>
  <td colspan=4><br /><br />Group Entries<br /><br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Node Signature</td>
  <td>The ASCII character string <code>SNOD</code> is used to indicate the beginning of a group node. This
      gives file consistency checking utilities a better chance of reconstructing a damaged file.</td>
</tr>
<tr valign=top>
  <td>Version Number</td>
  <td>The version number for the group node. This document describes version 1.</td>
</tr>
<tr valign=top>
  <td>Number of Symbols</td>
  <td>Although all group nodes have the same length, most contain fewer than the maximum possible number of
      symbol entries. This field indicates how many entries contain valid data. The valid entries are packed
      at the beginning of the group node while the remaining entries contain undefined values.</td>
</tr>
<tr valign=top>
  <td>Group Entries</td>
  <td>Each symbol has an entry in the group node. The format of the entry is described below.</td>
</tr>
</table>

\subsection subsec_fmt1_group_symboltableentry Disk Format: Level 1C - Group Entry
Each group entry in a group node is designed to allow for very fast browsing of stored objects. Toward that
design goal, the group entries include space for caching certain constant meta data from the object header.

<table>
<caption align="top"><strong>Group Entry</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Name Offset (&lt;size&gt; bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>Object Header Address</td>
</tr>
<tr align=center>
  <td colspan=4>Cache Type</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4><br /><br />Scratch-pad Space (16 bytes)<br /><br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Name Offset</td>
  <td>This is the byte offset into the group local heap for the name of the object. The name is null
    terminated.</td>
</tr>
<tr valign=top>
  <td>Object Header Address</td>
  <td>Every object has an object header which serves as a permanent location for the object's meta data.
      In addition to appearing in the object header, some meta data can be cached in the scratch-pad space.</td>
</tr>
<tr valign=top>
  <td>Cache Type</td>
  <td>The cache type is determined from the object header. It also determines the format for the scratch-pad
      space.<br />
      <dl compact>
        <dt>0</dt>
        <dd>No data is cached by the group entry. This is guaranteed to be the case when an object header has
            a link count greater than one.</dd>
        <dt>1</dt>
        <dd>Object header meta data is cached in the group entry. This implies that the group entry refers to
             another group.</dd>
        <dt>2</dt>
        <dd>The entry is a symbolic link. The first four bytes of the scratch-pad space are the offset into
            the local heap for the link value. The object header address will be undefined.</dd>
        <dt><em>N</em></dt>
        <dd>Other cache values can be defined later and libraries that do not understand the new values will
            still work properly.</dd>
      </dl>
  </td>
</tr>
<tr valign=top>
  <td>Reserved</td>
  <td>These four bytes are present so that the scratch-pad space is aligned on an eight-byte boundary. They
      are always set to zero.</td>
</tr>
<tr valign=top>
  <td>Scratch-pad Space</td>
  <td>This space is used for different purposes, depending on the value of the Cache Type field. Any meta-data
      about a dataset object represented in the scratch-pad space is duplicated in the object header for
      that dataset. This meta data can include the datatype and the size of the dataspace for a dataset whose
      datatype is atomic and whose dataspace is fixed and less than four dimensions. Furthermore, no data is
      cached in the group entry scratch-pad space if the object header for the group entry has a link count
      greater than one.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_group_symboltableentry_scratch Format of the Scratch-pad Space
The group entry scratch-pad space is formatted according to the value in the Cache Type field.

If the Cache Type field contains the value zero (<code>0</code>) then no information is stored in the
scratch-pad space.

If the Cache Type field contains the value one (<code>1</code>), then the scratch-pad space contains
cached meta data for another object header in the following format:
<table>
<caption align="top"><strong>Object Header Scratch-pad Format</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Address of B-tree</td>
</tr>
<tr align=center>
  <td colspan=4>Address of Name Heap</td>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Address of B-tree</td>
  <td>This is the file address for the root of the group's B-tree.</td>
</tr>
<tr valign=top>
  <td>Address of Name Heap</td>
  <td>This is the file address for the group's local heap, in which are stored the symbol names.</td>
</tr>
</table>

If the Cache Type field contains the value two (<code>2</code>), then the scratch-pad space contains
cached meta data for another symbolic link in the following format:
<table>
<caption align="top"><strong>Symbolic Link Scratch-pad Format</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Offset to Link Value</td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Offset to Link Value</td>
  <td>The value of a symbolic link (that is, the name of the thing to which it points) is stored in the
      local heap. This field is the 4-byte offset into the local heap for the start of the link value, which
      is null terminated.</td>
</tr>
</table>

\subsection subsec_fmt1_group_localheap Disk Format: Level 1D - Local Heaps
A heap is a collection of small heap objects. Objects can be inserted and removed from the heap at any time.
The address of a heap does not change once the heap is created. References to objects are stored in the group
table; the names of those objects are stored in the local heap.
<table>
<caption align="top"><strong>Local Heaps</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Heap Signature</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved (zero)</td>
</tr>
<tr align=center>
  <td colspan=4>Data Segment Size</td>
</tr>
<tr align=center>
  <td colspan=4>Offset to Head of Free-list (&lt;size&gt; bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>Address of Data Segment</td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Heap Signature</td>
  <td>The ASCII character string <code>HEAP</code> is used to indicate the beginning of a heap. This gives
      file consistency checking utilities a better chance of reconstructing a damaged file.</td>
</tr>
<tr valign=top>
  <td>Data Segment Size</td>
  <td>The total amount of disk memory allocated for the heap data. This may be larger than the amount of space
      required by the object stored in the heap. The extra unused space holds a linked list of free blocks.</td>
</tr>
<tr valign=top>
  <td>Offset to Head of Free-list</td>
  <td>This is the offset within the heap data segment of the first free block (or all 0xff bytes if there is
      no free block). The free block contains &lt;size&gt; bytes that are the offset of the next free chunk
      (or all 0xff bytes if this is the last free chunk) followed by &lt;size&gt; bytes that store the size
      of this free chunk.</td>
</tr>
<tr valign=top>
  <td>Address of Data Segment</td>
  <td>The data segment originally starts immediately after the heap header, but if the data segment must grow
      as a result of adding more objects, then the data segment may be relocated, in its entirety, to another
      part of the file.</td>
</tr>
</table>

Objects within the heap should be aligned on an 8-byte boundary.

\subsection subsec_fmt1_group_globalheap Disk Format: Level 1E - Global Heap
Each HDF5 file has a global heap which stores various types of information which is typically shared between
datasets. The global heap was designed to satisfy these goals:
<ol type="A">
  <li>Repeated access to a heap object must be efficient without resulting in repeated file I/O requests.
      Since global heap objects will typically be shared among several datasets, it is probable that the
      object will be accessed repeatedly.</li>
  <li>Collections of related global heap objects should result in fewer and larger I/O requests. For
      instance, a dataset of void pointers will have a global heap object for each pointer. Reading the
      entire set of void pointer objects should result in a few large I/O requests instead of one small
      I/O request for each object.</li>
  <li>It should be possible to remove objects from the global heap and the resulting file hole should be
      eligible to be reclaimed for other uses.</li>
</ol>

The implementation of the heap makes use of the memory management already available at the file level and
combines that with a new top-level object called a <em>collection</em> to achieve Goal B. The global heap is
the set of all collections. Each global heap object belongs to exactly one collection and each collection
contains one or more global heap objects. For the purposes of disk I/O and caching, a collection is treated
as an atomic object.

<table>
<caption align="top"><strong>A Global Heap Collection</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Magic Number</td>
</tr>
<tr align=center>
  <td>Version</td>
  <td colspan=3>Reserved</td>
</td>
<tr align=center>
  <td colspan=4>Collection Size</td>
</tr>
<tr align=center>
  <td colspan=4><br />Global Heap Object 1 <i>(described below)</i><br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Global Heap Object 2<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />...<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Global Heap Object <em>N</em><br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Global Heap Object 0 (free space)<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Magic Number</td>
  <td>The magic number for global heap collections are the four bytes <code>G</code>, <code>C</code>,
     <code>O</code>, and <code>L</code>.</td>
</tr>
<tr valign=top>
  <td>Version</td>
  <td>Each collection has its own version number so that new collections can be added to old files. This
      document describes version zero of the collections.</td>
</tr>
<tr valign=top>
  <td>Collection Data Size</td>
  <td>This is the size in bytes of the entire collection including this field. The default (and minimum)
    collection size is 4096 bytes which is a typical file system block size and which allows for 170 16-byte
    heap objects plus their overhead.</td>
</tr>
<tr valign=top>
  <td>Object 1 through <em>N</em></td>
  <td>The objects are stored in any order with no intervening unused space.</td>
</tr>
<tr valign=top>
  <td>Object 0</td>
  <td>Object 0 (zero), when present, represents the free space in the collection. Free space always appears
      at the end of the collection. If the free space is too small to store the header for Object 0 (described
      below) then the header is implied and the collection contains no free space.</td>
</tr>
</table>

<table>
<caption align="top"><strong>Global Heap Object</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=2>Object ID</td>
  <td colspan=2>Reference Count</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Object Data Size</td>
</tr>
<tr align=center>
  <td colspan=4><br />Object Data<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Object ID</td>
  <td>Each object has a unique identification number within a collection. The identification numbers are
      chosen so that new objects have the smallest value possible with the exception that the identifier
      <code>0</code> always refers to the object which represents all free space within the collection.</td>
</tr>
<tr valign=top>
  <td>Reference Count</td>
  <td>All heap objects have a reference count field. An object which is referenced from some other part of the
    file will have a positive reference count. The reference count for Object 0 is always zero.</td>
</tr>
<tr valign=top>
  <td>Reserved</td>
  <td>Zero padding to align next field on an 8-byte boundary.</td>
</tr>
<tr valign=top>
  <td>Object Size</td> <td>This is the size of the fields above plus the object data stored for the object.
      The actual storage size is rounded up to a multiple of eight.</td>
</tr>
<tr valign=top>
  <td>Object Data</td>
  <td>The object data is treated as a one-dimensional array of bytes to be interpreted by the caller.</td>
</tr>
</table>

\subsection subsec_fmt1_group_freespaceindex Disk Format: Level 1F - Free-space Heap
The Free-space Index is a collection of blocks of data, dispersed throughout the file, which are currently
not used by any file objects.

The super block contains a pointer to root of the free-space description; that pointer is currently (i.e., in
HDF5 Release 1.2) required to be the undefined address <code>0xfff...ff</code>.

The free-sapce index is not otherwise publicly defined at this time.

\section sec_fmt1_dataobject Disk Format: Level 2 - Data Objects
Data objects contain the real information in the file. These objects compose the scientific data and other
information which are generally thought of as "data" by the end-user. All the other information in the file
is provided as a framework for these data objects.

A data object is composed of header information and data information. The header information contains the
information needed to interpret the data information for the data object as well as additional "meta-data"
or pointers to additional "meta-data" used to describe or annotate each data object.

\subsection subsec_fmt1_dataobject_hdr Disk Format: Level 2a - Data Object Headers
The header information of an object is designed to encompass all the information about an object which would
be desired to be known, except for the data itself. This information includes the dimensionality, number-type,
information about how the data is stored on disk (in external files, compressed, broken up in blocks, etc.),
as well as other information used by the library to speed up access to the data objects or maintain a file's
integrity. The header of each object is not necessarily located immediately prior to the object's data in the
file and in fact may be located in any position in the file.

<table>
<caption align="top"><strong>Object Headers</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=1 width="25%">Version \# of Object Header</td>
  <td colspan=1 width="25%">Reserved</td>
  <td colspan=2 width="50%">Number of Header Messages</td>
</tr>
<tr align=center>
  <td colspan=4>Object Reference Count</td>
</tr>
<tr align=center>
  <td colspan=4><br />Total Object Header Size<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=2>Header Message Type \#1</td>
  <td colspan=2>Size of Header Message Data \#1</td>
</tr>
<tr align=center>
  <td>Flags</td>
  <td colspan=3>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4><br />Header Message Data \#1<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4>.<br />.<br />.<br /></td>
</tr>
<tr align=center>
  <td colspan=2>Header Message Type \#n</td>
  <td colspan=2>Size of Header Message Data \#n</td>
</tr>
<tr align=center>
  <td>Flags</td>
  <td colspan=3>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4><br />Header Message Data \#n<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version number of the object header</td>
  <td>This value is used to determine the format of the information in the object header. When the format of
      the information in the object header is changed, the version number is incremented and can be used to
      determine how the information in the object header is formatted.</td>
</tr>
<tr valign=top>
  <td>Reserved</td>
  <td>Always set to zero.</td>
</tr>
<tr valign=top>
  <td>Number of header messages</td>
  <td>This value determines the number of messages listed in this object header. This provides a fast way for
      software to prepare storage for the messages in the header.</td>
</tr>
<tr valign=top>
  <td>Object Reference Count</td>
  <td>This value specifies the number of references to this object within the current file. References to the
      data object from external files are not tracked.</td>
</tr>
<tr valign=top>
  <td>Total Object Header Size</td>
  <td>This value specifies the total number of bytes of header message data following this length field for the
      current message as well as any continuation data located elsewhere in the file.</td>
</tr>
<tr valign=top>
  <td>Header Message Type</td>
  <td>The header message type specifies the type of information included in the header message data following
      the type along with a small amount of other information. Bit 15 of the message type is set if the message
      is constant (constant messages cannot be changed since they may be cached in group entries throughout the
      file). The header message types for the pre-defined header messages will be included in further discussion
      below.</td>
</tr>
<tr valign=top>
  <td>Size of Header Message Data</td>
  <td>This value specifies the number of bytes of header message data following the header message type and
      length information for the current message. The size includes padding bytes to make the message a multiple
      of eight bytes.</td>
</tr>
<tr valign=top>
  <td>Flags</td>
  <td>This is a bit field with the following definition:
      <dl>
      <dt><code>0</code></dt>
      <dd>If set, the message data is constant. This is used for messages like the datatype message of a
          dataset.</dd>
      <dt><code>1</code></dt>
      <dd>If set, the message is stored in the global heap and the Header Message Data field contains a
          Shared Object message and the Size of Header Message Data field contains the size of that Shared
          Object message.</dd>
      <dt><code>2-7</code></dt>
      <dd>Reserved</dd>
      </dl>
  </td>
</tr>
<tr valign=top>
  <td>Header Message Data</td>
  <td>The format and length of this field is determined by the header message type and size respectively.
      Some header message types do not require any data and this information can be eliminated by setting the
      length of the message to zero. The data is padded with enough zeros to make the size a multiple of
      eight.</td>
</tr>
</table>

The header message types and the message data associated with them compose the critical "meta-data" about
each object. Some header messages are required for each object while others are optional. Some optional
header messages may also be repeated several times in the header itself, the requirements and number of
times allowed in the header will be noted in each header message description below.

The following is a list of currently defined header messages:

\subsubsection subsubsec_fmt1_dataobject_hdr_nil Name: NIL
<strong>Type: </strong>0x0000<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Optional, may be repeated.<br />
<strong>Purpose and Description:</strong> The NIL message is used to indicate a message which is to be ignored
when reading the header messages for a data object. [Probably one which has been deleted for some reason.]<br />
<strong>Format of Data:</strong> Unspecified.<br />

\subsubsection subsubsec_fmt1_dataobject_hdr_simple Name: Simple Dataspace
<strong>Type: </strong>0x0001<br />
<strong>Length:</strong> Varies according to the number of dimensions, as described in the following table<br />
<strong>Status:</strong> The <em>Simple Dataspace</em> message is required and may not be repeated. This message
is currently used with datasets and named dataspaces.<br />

The <em>Simple Dataspace</em> message describes the number of dimensions and size of each dimension that the
data object has. This message is only used for datasets which have a simple, rectilinear grid layout; datasets
requiring a more complex layout (irregularly structured or unstructured grids, etc.) must use the
<em>Complex Dataspace</em> message for expressing the space the dataset inhabits. <i>(Note: The
<em>Complex Dataspace</em> functionality is not yet implemented (as of HDF5 Release 1.2). It is not described
in this document.)</i>

<table>
<caption align="top"><strong>Simple Dataspace Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td>Version</td>
  <td>Dimensionality</td>
  <td>Flags</td>
  <td>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Dimension Size \#1 (&lt;size&gt; bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>.<br />.<br />.<br /></td>
</tr>
<tr align=center>
  <td colspan=4>Dimension Size \#n (&lt;size&gt; bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>Dimension Maximum \#1 (&lt;size&gt; bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>.<br />.<br />.<br /></td>
</tr>
<tr align=center>
  <td colspan=4>Dimension Maximum \#n (&lt;size&gt; bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>Permutation Index \#1</td>
</tr>
<tr align=center>
  <td colspan=4>.<br />.<br />.<br /></td>
</tr>
<tr align=center>
  <td colspan=4>Permutation Index \#n</td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version </td>
  <td>This value is used to determine the format of the Simple Dataspace Message. When the format of the
      information in the message is changed, the version number is incremented and can be used to determine
      how the information in the object header is formatted.</td>
</tr>
<tr valign=top>
  <td>Dimensionality</td>
  <td>This value is the number of dimensions that the data object has.</td>
</tr>
<tr valign=top>
  <td>Flags</td>
  <td>This field is used to store flags to indicate the presence of parts of this message. Bit 0 (the least
      significant bit) is used to indicate that maximum dimensions are present. Bit 1 is used to indicate
      that permutation indices are present for each dimension.</td>
</tr>
<tr valign=top>
  <td>Dimension Size \#n (&lt;size&gt; bytes)</td>
  <td>This value is the current size of the dimension of the data as stored in the file. The first dimension
      stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the
      fastest changing dimension.</td>
</tr>
<tr valign=top>
  <td>Dimension Maximum \#n (&lt;size&gt; bytes)</td>
  <td>This value is the maximum size of the dimension of the data as stored in the file.  This value may be
      the special value &lt;UNLIMITED&gt; (all bits set) which indicates that the data may expand along this
      dimension indefinitely. If these values are not stored, the maximum value of each dimension is assumed
      to be the same as the current size value.</td>
</tr>
<tr valign=top>
  <td>Permutation Index \#n (4 bytes)</td>
  <td>This value is the index permutation used to map each dimension from the canonical representation to an
    alternate axis for each dimension. If these values are not stored, the first dimension stored in the list
    of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing
    dimension.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_dtmessage Name: Datatype
<strong>Type:</strong> 0x0003<br />
<strong>Length:</strong> variable<br />
<strong>Status:</strong> One required per dataset or named datatype<br />

The datatype message defines the datatype for each data point of a dataset. A datatype can describe an atomic
type like a fixed- or floating-point type or a compound type like a C struct. A datatype does not, however,
describe how data points are combined to produce a dataset. Datatypes are stored on disk as a datatype message,
which is a list of datatype classes and their associated properties.

<table>
<caption align="top"><strong>Datatype Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td>Type Class and Version</td>
  <td colspan=3>Class Bit Field</td>
</tr>
<tr align=center>
  <td colspan=4>Size in Bytes (4 bytes)</td>
</tr>
<tr align=center>
  <td colspan=4><br /><br />Properties<br /><br> /<br /></td>
</tr>
</table>

The Class Bit Field and Properties fields vary depending on the Type Class, which is the low-order four bits
of the Type Class and Version field (the high-order four bits are the version, which should be set to the
value one). The type class is one of 0 (fixed-point number), 1 (floating-point number), 2 (date and time),
3 (text string), 4 (bit field), 5 (opaque), 6 (compound), 7 (reference), 8 (enumeration), or 9
(variable-length). The Class Bit Field is zero and the size of the Properties field is zero except for the
cases noted here.

<table>
<caption align="top">
  <strong>Bit Field for Fixed-point Numbers (Class 0)</strong>
</caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0</td>
  <td><strong>Byte Order.</strong> If zero, byte order is little-endian; otherwise, byte order is big endian.</td>
</tr>
<tr valign=top>
  <td>1, 2</td>
  <td><strong>Padding type.</strong> Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has
      unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.</td>
</tr>
<tr valign=top>
  <td>3</td>
  <td><strong>Signed.</strong> If this bit is set then the fixed-point number is in 2's complement form.</td>
</tr>
<tr valign=top>
  <td>4-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

<table>
<caption align="top">
  <strong>Properties for Fixed-point Numbers (Class 0)</strong>
</caption>
<tr align=center>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
</tr>
<tr align=center>
  <td colspan=2>Bit Offset</td>
  <td colspan=2>Bit Precision</td>
</tr>
</table>

<table>
<caption align="top"><strong>Bit Field for Floating-point Numbers (Class 1)</strong></caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0</td>
  <td><strong>Byte Order.</strong> If zero, byte order is little-endian; otherwise, byte order is big endian.</td>
</tr>
<tr valign=top>
  <td>1, 2, 3</td>
  <td><strong>Padding type.</strong>  Bit 1 is the low bits pad type, bit 2 is the high bits pad type, and bit
      3 is the internal bits pad type. If a datum has unused bits at either or between the sign bit, exponent,
      or mantissa, then the value of bit 1, 2, or 3 is copied to those locations.</td>
</tr>
<tr valign=top>
  <td>4-5</td>
  <td><strong>Normalization.</strong> The value can be 0 if there is no normalization, 1 if the most significant
      bit of the mantissa is always set (except for 0.0), and 2 if the most significant bit of the mantissa is not
      stored but is implied to be set. The value 3 is reserved and will not appear in this field.</td>
</tr>
<tr valign=top>
  <td>6-7</td>
  <td>Reserved (zero).</td>
</tr>
<tr valign=top>
  <td>8-15</td>
  <td><strong>Sign.</strong> This is the bit position of the sign bit.</td>
</tr>
<tr valign=top>
  <td>16-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

<table>
<caption align="top"><strong>Properties for Floating-point Numbers (Class 1)</strong></caption>
<tr align=center>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
</tr>
<tr align=center>
  <td colspan=2>Bit Offset</td>
  <td colspan=2>Bit Precision</td>
</tr>
<tr align=center>
  <td>Exponent Location</td>
  <td>Exponent Size in Bits</td>
  <td>Mantissa Location</td>
  <td>Mantissa Size in Bits</td>
</tr>
<tr align=center>
  <td colspan=4>Exponent Bias</td>
</tr>
</table>

<table>
<caption align="top"><strong>Bit Field for Strings (Class 3)</strong></caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0-3</td>
  <td><strong>Padding type.</strong> This four-bit value determines the type of padding to use for the
      string. The values are:
      <dl>
      <dt><code>0</code> Null terminate.</dt>
      <dd>A zero byte marks the end of the string and is guaranteed to be present after converting a long
          string to a short string. When converting a short string to a long string the value is padded with
          additional null characters as necessary.</dd>
      <dt><code>1</code> Null pad.</dt>
      <dd>Null characters are added to the end of the value during conversions from short values to long values
          but conversion in the opposite direction simply truncates the value.</dd>
      <dt><code>2</code> Space pad.</dt>
      <dd>Space characters are added to the end of the value during conversions from short values to long values
          but conversion in the opposite direction simply truncates the value. This is the Fortran
          representation of the string.</dd>
      <dt><code>3-15</code> Reserved.</dt>
      <dd>These values are reserved for future use.</dd>
    </dl>
</tr>
<tr valign=top>
  <td>4-7</td>
  <td><strong>Character Set.</strong> The character set to use for encoding the string. The only character set
      supported is the 8-bit ASCII (zero) so no translations have been defined yet.</td>
</tr>
<tr valign=top>
  <td>8-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

<table>
<caption align="top"><strong>Bit Field for Bitfield Types (Class 4)</strong></caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0</td>
  <td><strong>Byte Order.</strong> If zero, byte order is little-endian; otherwise, byte order is big endian.</td>
</tr>
<tr valign=top>
  <td>1, 2</td>
  <td><strong>Padding type.</strong> Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has
      unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.</td>
</tr>
<tr valign=top>
  <td>3-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

<table>
<caption align="top"><strong>Properties for Bitfield Types (Class 4)</strong></caption>
<tr align=center>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
</tr>
<tr align=center>
  <td colspan=2>Bit Offset</td>
  <td colspan=2>Bit Precision</td>
</tr>
</table>

<table>
<caption align="top"><strong>Bit Field for Opaque Types (Class 5)</strong></caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

<table>
<caption align="top"><strong>Properties for Opaque Types (Class 5)</strong></caption>
<tr align=center>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
</tr>
<tr align=center>
  <td colspan=4><br />Null-terminated ASCII Tag<br /> (multiple of 8 bytes)<br /><br /></td>
</tr>
</table>

<table>
<caption align="top"><strong>Bit Field for Compound Types (Class 6)</strong></caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0-15</td>
  <td><strong>Number of Members.</strong> This field contains the number of members defined for the
      compound datatype. The member definitions are listed in the Properties field of the data type
      message.</td>
</tr>
<tr valign=top>
  <td>15-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

The Properties field of a compound datatype is a list of the member definitions of the compound datatype.
The member definitions appear one after another with no intervening bytes. The member types are described
with a recursive datatype message.

<table>
<caption align="top"><strong>Properties for Compound Types (Class 6)</strong></caption>
<tr align=center>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
</tr>
<tr align=center>
  <td colspan=4><br /><br />Name (null terminated, multiple of eight bytes)<br /><br >/<br /></td>
</tr>
<tr align=center>
  <td colspan=4>Byte Offset of Member in Compound Instance</td>
</tr>
<tr align=center>
  <td>Dimensionality</td>
  <td colspan=3>reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Dimension Permutation</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Size of Dimension 0 (required)</td>
</tr>
<tr align=center>
  <td colspan=4>Size of Dimension 1 (required)</td>
</tr>
<tr align=center>
  <td colspan=4>Size of Dimension 2 (required)</td>
</tr>
<tr align=center>
  <td colspan=4>Size of Dimension 3 (required)</td>
</tr>
<tr align=center>
  <td colspan=4><br /><br />Member Type Message<br /><br /><br /></td>
</tr>
</table>

<table>
<caption align="top"><strong>Bit Field for Enumeration Types (Class 8)</strong></caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0-15</td>
  <td><strong>Number of Members.</strong> The number of name/value pairs defined for the enumeration type.</td>
</tr>
<tr valign=top>
  <td>16-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

<table>
<caption align="top"><strong>Properties for Enumeration Types (Class 8)</strong></caption>
<tr align=center>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
</tr>
<tr align=center>
  <td colspan=4><br />Parent Type<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Names<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Values<br /><br /></td>
</tr>
</table>

<table>
<tr align=left valign=top>
  <td valign=top width=20%>Parent Type:</td>
  <td valign=top>Each enumeration type is based on some parent type, usually an integer. The information
      for that parent type is described recursively by this field.</td>
</tr>
<tr align=left valign=top>
  <td valign=top>Names:</td>
  <td valign=top>The name for each name/value pair. Each name is stored as a null terminated ASCII string
      in a multiple of eight bytes. The names are in no particular order.</td>
</tr>
<tr align=left valign=top>
  <td valign=top>Values:</td>
  <td valign=top>The list of values in the same order as the names. The values are packed (no inter-value
      padding) and the size of each value is determined by the parent type.</td>
</tr>
</table>

<table>
<caption align="top"><strong>Bit Field for Variable-length Types (Class 9)</strong></caption>
<tr align=center>
  <th width="10%">Bits</th>
  <th width="90%">Meaning</th>
</tr>
<tr valign=top>
  <td>0-3</td>
  <td>
  <dl>
    <dt><strong>Type</strong></dt>
    <dt>0 Variable-length sequence</dt>
    <dd>This variable-length datatype can be of any sequence of data. Variable-length sequences do not
        have padding or character set information.</dd>
    <dt>1 Variable-length string</dt>
    <dd>This variable-length datatype is composed of a series of characters. Variable-length strings
        have padding and character set information.</dd>
  </dl></td>
</tr>
<tr valign=top>
  <td>4-7</td>
  <td>
  <dl>
    <dt><strong>Padding type</strong> (variable-length string only)</dt>
    <dd>This four-bit value determines the type of padding used for variable-length strings. The values
        are the same as for the string padding type, as follows:</dd>
    <dt>0 Null terminate</dt>
    <dd>A zero byte marks the end of a string and is guaranteed to be present after converting a long
        string to a short string. When converting a short string to a long string, the value is padded
        with additional null characters as necessary.</dd>
    <dt>1 Null pad</dt>
    <dd>Null characters are added to the end of the value during conversion from a short string to a
        longer string. Conversion from a long string to a shorter string simply truncates the value.</dd>
    <dt>2 Space pad</dt>
    <dd>Space characters are added to the end of the value during conversion from a short string to a
        longer string. Conversion from a long string to a shorter string simply truncates the value.
        This is the Fortran representation of the string.</dd>
    <dt>3-15 Reserved</dt>
    <dd>These values are reserved for future use.</dd>
  </dl></td>
</tr>
<tr valign=top>
  <td>8-11</td>
  <td>
  <dl>
    <dt><strong>Character set</strong> (variable-length string only)</dt>
    <dd>This four-bit value specifies the character set to be used for encoding the string.</dd>
    <dt>0 8-bit ASCII</dt>
    <dd>As of this writing (July 2002, Release 1.4.4), 8-bit ASCII is the only character set supported.
        Therefore, no translations have been defined.</dd>
  </dl></td>
</tr>
<tr valign=top>
  <td>12-23</td>
  <td>Reserved (zero).</td>
</tr>
</table>

<table>
<caption align="top"><strong>Properties for Variable-length Types (Class 9)</strong></caption>
<tr align=center>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
  <th width="25%">Byte</th>
</tr>
<tr align=center>
  <td colspan=4><br />Parent Type<br /><br /></td>
</tr>
</table>

<table>
<tr align=left valign=top>
  <td valign=top width=20%>Parent Type:</td>
  <td valign=top>Each variable-length type is based on some parent type. The information for that parent
      type is described recursively by this field.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_fvmessage Name: Data Storage - Fill Value
<strong>Type:</strong> 0x0004<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Optional, may not be repeated.<br />

The fill value message stores a single data point value which is returned to the application when an
uninitialized data point is read from the dataset. The fill value is interpreted with the same datatype as
the dataset. If no fill value message is present then a fill value of all zero is assumed.

<table>
<caption align="top"><strong>Fill Value Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Size (4 bytes)</td>
</tr>
<tr align=center>
  <td colspan=4><br />Fill Value<br /><br /></td>
</tr>
</table>
<br />
<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Size (4 bytes)</td>
  <td>This is the size of the Fill Value field in bytes.</td>
</tr>
<tr valign=top>
  <td>Fill Value</td>
  <td>The fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_message_0005 Name: Reserved - Not Assigned Yet
<strong>Type:</strong> 0x0005<br />
<strong>Length:</strong> N/A<br />
<strong>Status:</strong> N/A<br />

\subsubsection subsubsec_fmt1_dataobject_hdr_compact Name: Data Storage - Compact
<strong>Type:</strong> 0x0006<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Optional, may not be repeated.<br />

This message indicates that the data for the data object is stored within the current HDF file by including
the actual data as the header data for this message. The data is stored internally in the <em>normal
format</em>, i.e. in one chunk, uncompressed, etc.

Note that one and only one of the <em>Data Storage</em> headers can be stored for each data object.

<strong>Format of Data:</strong> The message data is actually composed of dataset data, so the format will
be determined by the dataset format.

\subsubsection subsubsec_fmt1_dataobject_hdr_external Name: Data Storage - External Data Files
<strong>Type:</strong> 0x0007<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Optional, may not be repeated.<br />

<p><strong>Purpose and Description:</strong> The external object message indicates that the data for an
object is stored outside the HDF5 file. The filename of the object is stored as a Universal Resource Location
(URL) of the actual filename containing the data. An external file list record also contains the byte offset
of the start of the data within the file and the amount of space reserved in the file for that data.

<table>
<caption align="top"><strong>External File List Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td>Version</td>
  <td colspan=3>Reserved</td>
</tr>
<tr align=center>
  <td colspan=2>Allocated Slots</td>
  <td colspan=2>Used Slots</td>
</tr>
<tr align=center>
  <td colspan=4><br />Heap Address<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Slot Definitions...<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version</td>
  <td>This value is used to determine the format of the External File List Message. When the format of the
      information in the message is changed, the version number is incremented and can be used to determine
      how the information in the object header is formatted.</td>
</tr>
<tr valign=top>
  <td>Reserved</td>
  <td>This field is reserved for future use.</td>
</tr>
<tr valign=top>
  <td>Allocated Slots</td>
  <td>The total number of slots allocated in the message. Its value must be at least as large as the value
      contained in the Used Slots field.</td>
</tr>
<tr valign=top>
  <td>Used Slots</td>
  <td>The number of initial slots which contain valid information. The remaining slots are zero filled.</td>
</tr>
<tr valign=top>
  <td>Heap Address</td>
  <td>This is the address of a local name heap which contains the names for the external files. The name at
      offset zero in the heap is always the empty string.</td>
</tr>
<tr valign=top>
  <td>Slot Definitions</td>
  <td>The slot definitions are stored in order according to the array addresses they represent. If more slots
      have been allocated than what has been used then the defined slots are all at the beginning of the list.</td>
</tr>
</table>

<table>
<caption align="top"><strong>External File List Slot</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4><br />Name Offset (&lt;size&gt; bytes)<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />File Offset (&lt;size&gt; bytes)<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Size<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Name Offset (&lt;size&gt; bytes)</td>
  <td>The byte offset within the local name heap for the name of the file. File names are stored as a URL
      which has a protocol name, a host name, a port number, and a file name:
      <code><em>protocol</em>:<em>port</em>//<em>host</em>/<em>file</em></code>. If the protocol is omitted
      then "file:" is assumed. If the port number is omitted then a default port for that protocol is used.
      If both the protocol and the port number are omitted then the colon can also be omitted. If the double
      slash and host name are omitted then "localhost" is assumed. The file name is the only mandatory part,
      and if the leading slash is missing then it is relative to the application's current working directory
      (the use of relative names is not recommended).</td>
</tr>
<tr valign=top>
  <td>File Offset (&lt;size&gt; bytes)</td>
  <td>This is the byte offset to the start of the data in the specified file. For files that contain data for
      a single dataset this will usually be zero.</td>
</tr>
<tr valign=top>
  <td>Size</td>
  <td>This is the total number of bytes reserved in the specified file for raw data storage. For a file that
    contains exactly one complete dataset which is not extendable, the size will usually be the exact size of
    the dataset. However, by making the size larger one allows HDF5 to extend the dataset. The size can be set
    to a value larger than the entire file since HDF5 will read zeros past the end of the file without failing.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_layout Name: Data Storage - Layout
<strong>Type:</strong> 0x0008<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Required for datasets, may not be repeated.

<strong>Purpose and Description:</strong> Data layout describes how the elements of a multi-dimensional array
are arranged in the linear address space of the file. Two types of data layout are supported:
<ol>
  <li>The array can be stored in one contiguous area of the file. The layout requires that the size of the
      array be constant and does not permit chunking, compression, checksums, encryption, etc. The message
      stores the total size of the array and the offset of an element from the beginning of the storage area
      is computed as in C.</li>
  <li>The array domain can be regularly decomposed into chunks and each chunk is allocated separately. This
      layout supports arbitrary element traversals, compression, encryption, and checksums, and the chunks
      can be distributed across external raw data files (these features are described in other messages).
      The message stores the size of a chunk instead of the size of the entire array; the size of the entire
      array can be calculated by traversing the B-tree that stores the chunk addresses.</li>
</ol>

<table>
<caption align="top"><strong>Data Layout Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td>Version</td>
  <td>Dimensionality</td>
  <td>Layout Class</td>
  <td>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4><br />Address<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4>Dimension 0 (4-bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>Dimension 1 (4-bytes)</td>
</tr>
<tr align=center>
  <td colspan=4>...</td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version</td>
  <td>A version number for the layout message. This documentation describes version one.</td>
</tr>
<tr valign=top>
  <td>Dimensionality</td>
  <td>An array has a fixed dimensionality. This field specifies the number of dimension size fields later
      in the message.</td>
</tr>
<tr valign=top>
  <td>Layout Class</td>
  <td>The layout class specifies how the other fields of the layout message are to be interpreted. A value
      of one indicates contiguous storage while a value of two indicates chunked storage. Other values will
      be defined in the future.</td>
</tr>
<tr valign=top>
  <td>Address</td>
  <td>For contiguous storage, this is the address of the first byte of storage. For chunked storage this is
      the address of the B-tree that is used to look up the addresses of the chunks.</td>
</tr>
<tr valign=top>
  <td>Dimensions</td>
  <td>For contiguous storage the dimensions define the entire size of the array while for chunked storage
      they define the size of a single chunk.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_message_0009 Name: Reserved - Not Assigned Yet
<strong>Type:</strong> 0x0009<br />
<strong>Length:</strong> N/A<br />
<strong>Status:</strong> N/A<br />
<strong>Purpose and Description:</strong> N/A<br />
<strong>Format of Data:</strong> N/A

\subsubsection subsubsec_fmt1_dataobject_hdr_message_000A Name: Reserved - Not Assigned Yet
<strong>Type:</strong> 0x000A<br />
<strong>Length:</strong> N/A<br />
<strong>Status:</strong> N/A<br />
<strong>Purpose and Description:</strong> N/A<br />
<strong>Format of Data:</strong> N/A

\subsubsection subsubsec_fmt1_dataobject_hdr_filter Name: Data Storage - Filter Pipeline
<strong>Type:</strong> 0x000B<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Optional, may not be repeated.

<strong>Purpose and Description:</strong> This message describes the filter pipeline which should be
applied to the data stream by providing filter identification numbers, flags, a name, an client data.

<table>
<caption align="top"><strong>Filter Pipeline Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td>Version</td>
  <td>Number of Filters</td>
  <td colspan=2>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4><br />Filter List<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version</td>
  <td>The version number for this message. This document describes version one.</td>
</tr>
<tr valign=top>
  <td>Number of Filters</td>
  <td>The total number of filters described by this message. The maximum possible number of filters in a
      message is 32.</td>
</tr>
<tr valign=top>
  <td>Filter List</td>
  <td>A description of each filter. A filter description appears in the next table.</td>
</tr>
</table>

<table>
<caption align="top"><strong>Filter Pipeline Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=2>Filter Identification</td>
  <td colspan=2>Name Length</td>
</tr>
<tr align=center>
  <td colspan=2>Flags</td>
  <td colspan=2>Client Data Number of Values</td>
</tr>
<tr align=center>
  <td colspan=4><br />Name<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Client Data<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4>Padding</td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Filter Identification</td>
  <td>This is a unique (except in the case of testing) identifier for the filter. Values from zero through
      255 are reserved for filters defined by the NCSA HDF5 library. Values 256 through 511 have been set
      aside for use when developing/testing new filters. The remaining values are allocated to specific
      filters by contacting the <a href="mailto:help@hdfgroup.org">HDF5 development team</a>.</td>
</tr>
<tr valign=top>
  <td>Name Length</td>
  <td>Each filter has an optional null-terminated ASCII name and this field holds the length of the name
      including the null termination padded with nulls to be a multiple of eight. If the filter has no name
      then a value of zero is stored in this field.</td>
</tr>
<tr valign=top>
  <td>Flags</td>
  <td>The flags indicate certain properties for a filter. The bit values defined so far are:
    <dl>
      <dt><code>bit 1</code></dt>
      <dd>If set then the filter is an optional filter. During output, if an optional filter fails it will
          be silently removed from the pipeline.</dd>
    </dl></td>
</tr>
<tr valign=top>
  <td>Client Data Number of Values</td>
  <td>Each filter can store a few integer values to control how the filter operates. The number of entries
      in the Client Data array is stored in this field.</td>
</tr>
<tr valign=top>
  <td>Name</td>
  <td>If the Name Length field is non-zero then it will contain the size of this field, a multiple of eight.
      This field contains a null-terminated, ASCII character string to serve as a comment/name for the filter.</td>
</tr>
<tr valign=top>
  <td>Client Data</td>
  <td>This is an array of four-byte integers which will be passed to the filter function.  The Client Data
      Number of Values determines the number of elements in the array.</td>
</tr>
<tr valign=top>
  <td>Padding</td>
  <td>Four bytes of zeros are added to the message at this point if the Client Data Number of Values field
      contains an odd number.</td>
</tr>
 </table>

\subsubsection subsubsec_fmt1_dataobject_hdr_attribute Name: Attribute
<strong>Type:</strong> 0x000C<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Optional, may be repeated.<br />

<strong>Purpose and Description:</strong> The <em>Attribute</em> message is used to list objects in the HDF
file which are used as attributes, or "meta-data" about the current object. An attribute is a small dataset;
it has a name, a datatype, a data space, and raw data. Since attributes are stored in the object header they
must be relatively small (<64kb) and can be associated with any type of object which has an object header
(groups, datasets, named types and spaces, etc.).

<table>
<caption align="top"><strong>Attribute Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td>Version</td>
  <td>Reserved</td>
  <td colspan=2>Name Size</td>
</tr>
<tr align=center>
  <td colspan=2>Type Size</td>
  <td colspan=2>Space Size</td>
</tr>
<tr align=center>
  <td colspan=4><br />Name<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Type<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Space<br /><br /></td>
</tr>
<tr align=center>
  <td colspan=4><br />Data<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version</td>
  <td>Version number for the message. This document describes version 1 of attribute messages.</td>
</tr>
<tr valign=top>
  <td>Reserved</td>
  <td>This field is reserved for later use and is set to zero.</td>
</tr>
<tr valign=top>
  <td>Name Size</td>
  <td>The length of the attribute name in bytes including the null terminator. Note that the Name field
      below may contain additional padding not represented by this field.</td>
</tr>
<tr valign=top>
  <td>Type Size</td>
  <td>The length of the datatype description in the Type field below. Note that the Type field may contain
      additional padding not represented by this field.</td>
</tr>
<tr valign=top>
  <td>Space Size</td>
  <td>The length of the dataspace description in the Space field below. Note that the Space field may contain
      additional padding not represented by this field.</td>
</tr>
<tr valign=top>
  <td>Name</td>
  <td>The null-terminated attribute name. This field is padded with additional null characters to make it a
      multiple of eight bytes.</td>
</tr>
<tr valign=top>
  <td>Type</td>
  <td>The datatype description follows the same format as described for the datatype object header message.
      This field is padded with additional zero bytes to make it a multiple of eight bytes.</td>
</tr>
<tr valign=top>
  <td>Space</td>
  <td>The dataspace description follows the same format as described for the dataspace object header message.
      This field is padded with additional zero bytes to make it a multiple of eight bytes.</td>
</tr>
<tr valign=top>
  <td>Data</td>
  <td>The raw data for the attribute. The size is determined from the datatype and dataspace descriptions.
      This field is <em>not</em> padded with additional zero bytes.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_name Name: Object Name
<strong>Type:</strong> 0x000D<br />
<strong>Length:</strong> varies<br />
<strong>Status:</strong> Optional, may not be repeated.

<strong>Purpose and Description:</strong> The object name or comment is designed to be a short description
of an object. An object name is a sequence of non-zero (<code>\0</code>) ASCII characters with no other
formatting included by the library.

<table>
<caption align="top"><strong>Name Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4><br />Name<br /<>br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Name</td>
  <td>A null terminated ASCII character string.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_modified Name: Object Modification Date &amp; Time
<strong>Type:</strong> 0x000E<br />
<strong>Length:</strong> fixed<br />
<strong>Status:</strong> Optional, may not be repeated.

<strong>Purpose and Description:</strong> The object modification date and time is a timestamp which
indicates (using ISO-8601 date and time format) the last modification of an object. The time is
 updated when any object header message changes according to the system clock where the change was posted.

<table>
<caption align="top"><strong>Modification Time Message</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>Year</td>
</tr>
<tr align=center>
  <td colspan=2>Month</td>
  <td colspan=2>Day of Month</td>
</tr>
<tr align=center>
  <td colspan=2>Hour</td>
  <td colspan=2>Minute</td>
</tr>
<tr align=center>
  <td colspan=2>Second</td>
  <td colspan=2>Reserved</td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Year</td>
  <td>The four-digit year as an ASCII string. For example, <code>1998</code>. All fields of this message
      should be interpreted as coordinated universal time (UTC)</td>
</tr>
<tr valign=top>
  <td>Month</td>
  <td>The month number as a two digit ASCII string where January is <code>01</code> and December is
      <code>12</code>.</td>
</tr>
<tr valign=top>
  <td>Day of Month</td>
  <td>The day number within the month as a two digit ASCII string. The first day of the month is
      <code>01</code>.</td>
</tr>
<tr valign=top>
  <td>Hour</td>
  <td>The hour of the day as a two digit ASCII string where midnight is <code>00</code> and 11:00pm
      is <code>23</code>.</td>
</tr>
<tr valign=top>
  <td>Minute</td>
  <td>The minute of the hour as a two digit ASCII string where the first minute of the hour is
      <code>00</code> and the last is <code>59</code>.</td>
</tr>
<tr valign=top>
  <td>Second</td>
  <td>The second of the minute as a two digit ASCII string where the first second of the minute is
      <code>00</code> and the last is <code>59</code>.</td>
</tr>
<tr valign=top>
  <td>Reserved</td>
  <td>This field is reserved and should always be zero.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_shared Name: Shared Object Message
<strong>Type:</strong> 0x000F<br />
<strong>Length:</strong> 4 Bytes<br />
<strong>Status:</strong> Optional, may be repeated.

A constant message can be shared among several object headers by writing that message in the global
heap and having the object headers all point to it.  The pointing is accomplished with a Shared Object
message which is understood directly by the object header layer of the library. It is also possible to
have a message of one object header point to a message in some other object header, but care must be
exercised to prevent cycles.

If a message is shared, then the message appears in the global heap and its message ID appears in the
Header Message Type field of the object header. Also, the Flags field in the object header for that
message will have bit two set (the <code>H5O_FLAG_SHARED</code> bit). The message body in the object
header will be that of a Shared Object message defined here and not that of the pointed-to message.

<table>
<caption align="top"><strong>Shared Message Message</strong></caption>
<tr align=center>
  <th width="25%">byte</td>
  <th width="25%">byte</td>
  <th width="25%">byte</td>
  <th width="25%">byte</td>
</tr>
<tr align=center>
  <td>Version</td>
  <td>Flags</td>
  <td colspan=2>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4>Reserved</td>
</tr>
<tr align=center>
  <td colspan=4><br />Pointer<br /><br /></td>
</tr>
</table>

<table>
<tr>
  <th width="30%">Field Name</th>
  <th width="70%">Description</th>
</tr>
<tr valign=top>
  <td>Version</td>
  <td>The version number for the message. This document describes version one of shared messages.</td>
</tr>
<tr valign=top>
  <td>Flags</td>
  <td>The Shared Message message points to a message which is shared among multiple object headers. The
      Flags field describes the type of sharing:
      <dl>
        <dt><code>Bit 0</code></dt>
        <dd>If this bit is clear then the actual message is the first message in some other object header;
            otherwise the actual message is stored in the global heap.</dd>
        <dt><code>Bits 2-7</code></dt>
        <dd>Reserved (always zero)</dd>
     </dl></td>
</tr>
<tr valign=top>
  <td>Pointer</td>
  <td>This field points to the actual message. The format of the pointer depends on the value of the Flags
      field. If the actual message is in the global heap then the pointer is the file address of the global
      heap collection that holds the message, and a four-byte index into that collection. Otherwise the
      pointer is a group entry that points to some other object header.</td>
</tr>
</table>

\subsubsection subsubsec_fmt1_dataobject_hdr_continuation Name: Object Header Continuation
<strong>Type:</strong> 0x0010<br />
<strong>Length:</strong> fixed<br />
<strong>Status:</strong> Optional, may be repeated.<br />
<strong>Purpose and Description:</strong> The object header continuation is the location in the file of more
header messages for the current data object. This can be used when header blocks are large, or likely to
change over time.<br />
<strong>Format of Data:</strong> The object header continuation is formatted as follows (assuming a 4-byte
length &amp; offset are being used in the current file):
<table>
<caption align=bottom><strong>HDF5 Object Header Continuation Message Layout</strong></caption>
<tr align=center>
  <th width=25%>byte</th>
  <th width=25%>byte</th>
  <th width=25%>byte</th>
  <th width=25%>byte</th>
</tr>
<tr align=center>
  <td colspan=4>Header Continuation Offset</td>
</tr>
<tr align=center>
  <td colspan=4>Header Continuation Length</td>
</tr>
</table>

<dl>
  <dt>The elements of the Header Continuation Message are described below:</dt>
  <dd>
    <dl>
      <dt>Header Continuation Offset: (&lt;offset&gt; bytes)</dt>
      <dd>This value is the offset in bytes from the beginning of the file where the header continuation
          information is located.</dd>
      <dt>Header Continuation Length: (&lt;length&gt; bytes)</dt>
      <dd>This value is the length in bytes of the header continuation information in the file.</dd>
    </dl></dd>
</dl>

\subsubsection subsubsec_fmt1_dataobject_hdr_stmgroup Name: Group Message
<strong>Type:</strong> 0x0011<br />
<strong>Length:</strong> fixed<br />
<strong>Status:</strong> Required for groups, may not be repeated.<br />
<strong>Purpose and Description:</strong> Each group has a B-tree and a name heap which are pointed to
by this message.<br />
<strong>Format of data:</strong>

The group message is formatted as follows:
<table>
<caption align=bottom><strong>HDF5 Object Header Group Message Layout</strong></caption>
<tr align=center>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
  <th width="25%">byte</th>
</tr>
<tr align=center>
  <td colspan=4>B-tree Address</td>
</tr>
<tr align=center>
  <td colspan=4>Heap Address</td>
</tr>
</table>

<dl>
  <dt>The elements of the Group Message are described below:</dt>
  <dd>
    <dl>
      <dt>B-tree Address (&lt;offset&gt; bytes)</dt>
      <dd>This value is the offset in bytes from the beginning of the file where the B-tree is located.</dd>
      <dt>Heap Address (&lt;offset&gt; bytes)</dt>
      <dd>This value is the offset in bytes from the beginning of the file where the group name heap
          is located.</dd>
    </dl></dd>
</dl>

\subsection subsec_fmt1_dataobject_sharedhdr Disk Format: Level 2b - Shared Data Object Headers
In order to share header messages between several dataset objects, object header messages may be placed
into the global heap. Since these messages require additional information beyond the basic object header
message information, the format of the shared message is detailed below.

<table>
<caption align=bottom><strong>HDF5 Shared Object Header Message</strong></caption>
<tr align=center>
  <th width=25%>byte</th>
  <th width=25%>byte</th>
  <th width=25%>byte</th>
  <th width=25%>byte</th>
</tr>
<tr align=center>
  <td colspan=4>Reference Count of Shared Header Message</td>
</tr>
<tr align=center>
  <td colspan=4><br /> Shared Object Header Message<br /> <br /></td>
</tr>
</table>

<dl>
  <dt> The elements of the shared object header message are described below:</dt>
  <dd>
    <dl>
      <dt>Reference Count of Shared Header Message: (32-bit unsigned integer)</dt>
      <dd>This value is used to keep a count of the number of dataset objects which refer to this message
          from their dataset headers. When this count reaches zero, the shared message header may be
          removed from the global heap.</dd>
      <dt>Shared Object Header Message: (various lengths)</dt>
      <dd>The data stored for the shared object header message is formatted in the same way as the private
          object header messages described in the object header description earlier in this document and
          begins with the header message Type.</dd>
    </dl></dd>
</dl>

\subsection subsec_fmt1_dataobject_storage Disk Format: Level 2c - Data Object Data Storage
The data for an object is stored separately from the header information in the file and may not actually
be located in the HDF5 file itself if the header indicates that the data is stored externally. The
information for each record in the object is stored according to the dimensionality of the object
(indicated in the dimensionality header message). Multi-dimensional data is stored in C order [same
as current scheme], i.e. the "last" dimension changes fastest.

Data whose elements are composed of simple number-types are stored in native-endian IEEE format, unless
they are specifically defined as being stored in a different machine format with the architecture-type
information from the number-type header message. This means that each architecture will need to
[potentially] byte-swap data values into the internal representation for that particular machine.

Data with a "variable" sized number-type is stored in a data heap internal to the HDF5 file. Global heap
identifiers are stored in the data object storage.

Data whose elements are composed of pointer number-types are stored in several different ways depending
on the particular pointer type involved. Simple pointers are just stored as the dataset offset of the
object being pointed to with the size of the pointer being the same number of bytes as offsets in the file.
Partial-object pointers are stored as a heap-ID which points to the following information within the
file-heap: an offset of the object pointed to, number-type information (same format as header message),
dimensionality information (same format as header message), sub-set start and end information (i.e. a
coordinate location for each), and field start and end names (i.e.  a [pointer to the] string indicating
the first field included and a [pointer to the] string name for the last field).

Data of a compound datatype is stored as a contiguous stream of the items in the structure, with each
item formatted according to its datatype.

<hr>
Navigate back: \ref index "Main" / \ref SPEC

*/
