<!-- Converted by db4-upgrade version 1.0 -->

<article xmlns="http://docbook.org/ns/docbook" version="5.0" class="specification">
  <info>
    <title>BRL-CAD Database Format</title>
    <subtitle>Version 5 (DRAFT)</subtitle>
    
    <authorgroup>
      <author><personname><firstname>Lee</firstname><surname>Butler</surname><othername role="mi">A</othername></personname><affiliation>
          <shortaffil>U.S. Army Research Laboratory</shortaffil>
          <orgdiv>Survivability/Lethality Analysis Directorate</orgdiv>
          <address>
            Aberdeen Proving Ground
            <state>MD</state> 
            <postcode>21005-5068</postcode>
          </address>
        </affiliation></author>
      <author><personname><firstname>Michael</firstname><surname>Muuss</surname><othername role="mi">John</othername></personname><affiliation>
          <shortaffil>U.S. Army Research Laboratory</shortaffil>
          <orgdiv>Survivability/Lethality Analysis Directorate</orgdiv>
          <address>
            Aberdeen Proving Ground
            <state>MD</state> 
            <postcode>21005-5068</postcode>
          </address>
        </affiliation></author>
      <author><personname><firstname>Paul</firstname><surname>Tanenbaum</surname><othername role="mi">J</othername></personname><affiliation>
          <shortaffil>U.S. Army Research Laboratory</shortaffil>
          <orgdiv>Survivability/Lethality Analysis Directorate</orgdiv>
          <address>
            Aberdeen Proving Ground
            <state>MD</state> 
            <postcode>21005-5068</postcode>
          </address>
        </affiliation></author>
      <author><personname><firstname>John</firstname><surname>Anderson</surname><othername role="mi">R</othername></personname><affiliation>
          <shortaffil>U.S. Army Research Laboratory</shortaffil>
          <orgdiv>Survivability/Lethality Analysis Directorate</orgdiv>
          <address>
            Aberdeen Proving Ground
            <state>MD</state> 
            <postcode>21005-5068</postcode>
          </address>
        </affiliation></author>
      <author><personname><firstname>Robert</firstname><surname>Parker</surname><othername role="mi">G</othername></personname><affiliation>
          <shortaffil>U.S. Army Research Laboratory</shortaffil>
          <orgdiv>Survivability/Lethality Analysis Directorate</orgdiv>
          <address>
            Aberdeen Proving Ground
            <state>MD</state> 
            <postcode>21005-5068</postcode>
          </address>
        </affiliation></author>
      <author><personname><firstname>Ronald</firstname><surname>Bowers</surname><othername role="mi">A</othername></personname><affiliation>
          <shortaffil>U.S. Army Research Laboratory</shortaffil>
          <orgdiv>Survivability/Lethality Analysis Directorate</orgdiv>
          <address>
            Aberdeen Proving Ground
            <state>MD</state> 
            <postcode>21005-5068</postcode>
          </address>
        </affiliation></author>
      <author><personname><firstname>Christopher</firstname><surname>Johnson</surname><othername role="mi">T</othername></personname><affiliation>
          <shortaffil>U.S. Army Research Laboratory</shortaffil>
          <orgdiv>Survivability/Lethality Analysis Directorate</orgdiv>
          <address>
            Aberdeen Proving Ground
            <state>MD</state> 
            <postcode>21005-5068</postcode>
          </address>
        </affiliation></author>
      <author><personname><firstname>Eric</firstname><surname>Edwards</surname><othername role="mi">W</othername></personname><affiliation>
          <shortaffil>SURVICE Engineering Company</shortaffil>
          <address>
            <street>4695 Millennium Drive</street>
            <city>Belcamp</city>
            <state>MD</state> 
            <postcode>21017-1505</postcode>
          </address>
        </affiliation></author>
    </authorgroup>
  </info>

  <section>
    <title>Background and Terminology</title>
    
    <para>
      BRL-CAD is a constructive solid geometry (CSG) modeling system. Primitive solid shapes 
      are combined using boolean operations to form regions of homogeneous material. 
    </para>
    <para>
      The database is organized as a <emphasis>directed acyclic graph</emphasis> (DAG), which 
      comprises 

      <itemizedlist>
	<listitem>
	  <para>primitive <emphasis>solids</emphasis> - the minimal elements of the DAG.</para>
	</listitem>
	<listitem>
	  <para>
	    <emphasis>combinations</emphasis> - the nonminimal elements of the DAG, 
	    some of which are specially marked as regions. The maximal 
	    elements of the DAG are called tops.
	  </para>
	</listitem>
	<listitem>
	  <para><emphasis>arcs</emphasis> - contain boolean operators and 4x4 homogeneous transformation matrices.</para>
	</listitem>
      </itemizedlist>
    </para>
    <para>
      In a slight abuse of terminology, the DAG is often spoken of as a tree or collection 
      of trees. In this context, the solids are also called <emphasis>leaves</emphasis>. 
    </para>

    <section>
      <title>Format of Data Elements/Database External Format</title>
      
      <para>
	The external format has several important properties, especially with regard 
	to the <emphasis>Object_Body</emphasis>:
	<itemizedlist>
	  <listitem>
	    <para>
	      Numbers are stored in binary for storage efficiency, for speed of reading 
	      and writing, and for preventing errors from creeping in due to repetitive 
	      conversion between binary and an ASCII string representation. This eliminates 
	      the need to use the old g2asc and asc2g to move databases between machines of 
	      different architectures.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      All data in the object wrapper are stored in a machine-independent format, 
	      as follows:
	      <itemizedlist mark="opencircle">
		<listitem>
		  <para>
		    All floating point numbers are stored as IEEE double-precision, in 
		    big-endian order, where byte 0 is on the left end of the word.
		  </para>
		</listitem>
		<listitem>
		  <para>
		    All integers are stored as either <emphasis>unsigned</emphasis> or 
		    <emphasis>twos-complement signed</emphasis> binary numbers in either 
		    8, 16, 32, or 64 bits, in big-endian order.
		  </para>
		</listitem>
		<listitem>
		  <para>
		    All character strings are stored in the ASCII 8-bit character set. 
		    A string is stored as an integer followed by an array of 8-bit 
		    characters. The last character in the array is always a null byte. 
		    The integer indicates the number of bytes in the array including the 
		    terminating null.
		  </para>
		</listitem>
	      </itemizedlist>
	    </para>
	  </listitem>
	</itemizedlist>
      </para>
    </section>
  </section>

  <section>
    <title>Definition of a Single, Generic Database Object</title>
    
    <para>
      The database access library stores <emphasis>objects</emphasis> as a collection 
      of data with a globally unique name and places no interpretation on the content 
      of those data. The <emphasis>object</emphasis> is the smallest granularity of 
      an item in the database; objects must be read from and written to the database 
      in a single atomic operation.
    </para>
    <para>
      In the case of librt, each database object will contain exactly one combination 
      node or leaf (solid) node. 
    </para>

    <section>
      <title>Object Structure</title>
      
      <para>
	All objects share certain common properties, which are stored in a standardized 
	<emphasis>object wrapper</emphasis> consisting of an Object Header and an Object Footer.
      </para>
      <para>
	The Object Header consists of:
	<itemizedlist>
	  <listitem>
	    <para>
	      An 8-bit Magic1 element that holds a specific magic number value used for 
	      database integrity checking.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      A 16-bit Flags element consisting of three 8-bit fields: HFlags, AFlags, 
	      and BFlags, described later.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      A 16-bit Object_Type element organized into two 8-bit-wide fields: the 
	      Major_Type and the Minor_Type.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      An Object_Length element that indicates the total number of bytes required 
	      for this object, including the magic numbers.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      An Object_Name element that is a string holding a name unique to that object 
	      and drawn from a name space that is global to the database. Like other strings, 
	      it consists of two fields, Length and Data. In the case of the Object_Name 
	      element, these are referred to as Name_Length and Name_Data, respectively. 
	      Note: The Object_Name element is mandatory for all allocated storage in the 
	      database. Database free-space managment objects are the only objects for which 
	      the Object_Name element is optional.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>
      <para>
	The Object Footer consists of:
	<itemizedlist>
	  <listitem>
	    <para>
	      Any padding bytes necessary to bring the total size of the object in bytes to an 
	      integral multiple of 8.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      An 8-bit Magic2 element that holds a specific magic number value used for database 
	      integrity checking.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>
      <para>
	Objects may store application-specific information in an Object Interior.
	<itemizedlist>
	  <listitem>
	    <para>
	      An object may optionally have an Object_Attributes element consisting of a
	      pair of fields: Attribute_Length and Attribute_Data. From the point of view 
	      of the database interface specification, the names and values of these attributes 
	      are opaque????; a standardized import/export encoding API will be provided.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      An object may optionally have an Object_Body element consisting of a pair of 
	      fields, Body_Length and Body_Data. From the point of view of the database 
	      interface specification, the format of the data is opaque??.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>
      <para>
	The on-disk version of each object consists of three distinct parts: Object Header, 
	Object Interior, and Object Footer. This is called the external format of the object.
      </para>

      <table frame="all">
        <title>On-Disk BRL-CAD Object Structure</title>

	<tgroup cols="3" align="center" colsep="1" rowsep="1">
	  <thead>
	    <row>
	      <entry>Part</entry>
	      <entry>Element</entry>
	      <entry>Comments</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry morerows="4" valign="middle"><para>Object Header:</para><para>(not compressible)</para></entry>
	      <entry>Magic1</entry>
	      <entry morerows="2" valign="middle">Required</entry>
	    </row>
	    <row>
	      <entry>HFlags, AFlags, BFlags</entry>
	    </row>
	    <row>
	      <entry><para>Object_Type</para><para>(Major_Type, Minor_Type)</para></entry>
	    </row>
	    <row>
	      <entry>Object_Length</entry>
	      <entry>Required</entry>
	    </row>
	    <row>
	      <entry align="center">
		<para>
		  <informaltable frame="none">
		    <tgroup cols="2" align="center">
		      <tbody>
			<row>
			  <entry>Object Name:</entry>
			  <entry>
			    <para>
			      <informaltable frame="all">
				<tgroup cols="1" align="center">
				  <tbody>
				    <row><entry>Name_Length</entry></row>
				    <row><entry>Name_Data</entry></row>
				  </tbody>
				</tgroup>
			      </informaltable>
			    </para>
			  </entry>
			</row>
		      </tbody>
		    </tgroup>
		  </informaltable>
		</para>
	      </entry>
	      <entry><para>Conditional on flag bit N,</para><para>Required for Application Data</para></entry>
	    </row>
	    <row>
	      <entry morerows="1" valign="middle"><para>Object Interior:</para><para>(individually compressible)</para></entry>
	      <entry align="center">
		<para>
		  <informaltable frame="none">
		    <tgroup cols="2" align="center">
		      <tbody>
			<row>
			  <entry>Object Attributes:</entry>
			  <entry>
			    <para>
			      <informaltable frame="all">
				<tgroup cols="1" align="center">
				  <tbody>
				    <row><entry>Attribute_Length</entry></row>
				    <row><entry>Attribute_Data</entry></row>
				</tbody>
			      </tgroup>
			    </informaltable>
			  </para>
			</entry>
		      </row>
		    </tbody>
		  </tgroup>
		</informaltable>
		</para>
	      </entry>
	      <entry><para>Conditional on flag bit A</para><para>(ZZZ compression)</para></entry>
	    </row>
	    <row>
	      <entry align="center">
		<para>
		<informaltable frame="none">
		  <tgroup cols="2" align="center">
		    <tbody>
		      <row>
			<entry>Object Body:</entry>
			<entry>
			  <para>
			    <informaltable frame="all">
			      <tgroup cols="1" align="center">
				<tbody>
				  <row><entry>Body_Length</entry></row>
				  <row><entry>Body_Data</entry></row>
				</tbody>
			      </tgroup>
			    </informaltable>
			  </para>
			</entry>
		      </row>
		    </tbody>
		  </tgroup>
		</informaltable>
		</para>
	      </entry>
	      <entry><para>Conditional on flag bit B</para><para>(ZZZ compression)</para></entry>
	    </row>
	    <row>
	      <entry morerows="1" valign="middle"><para>Object Footer:</para><para>(not compressible)</para></entry>
	      <entry>Padding</entry>
	      <entry><para>As required to maintain 8-byte</para><para>object boundaries</para></entry>
	    </row>
	    <row>
	      <entry>Magic2</entry>
	      <entry>Required</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>

      <para>
	????Need a description that says that an object can now have (1) EITHER an attribute OR a
	body, (2) BOTH an attribute and a body, or (3) NEITHER an attribute nor a body.
      </para>
      <para>
	The routines db_get_external() and db_put_external() are used to move objects in external
	format between memory and the database disk file. The routines db_wrap_external() and
	db_unwrap_external() are used to wrap and unwrap the (??? Object_Body or Object_Interior ???)
	(already in external form) in a standardized database object's wrapper.
      </para>
    </section>

    <section>
      <title>Flags</title>

      <para>
	The Flags element consists of three 8-bit fields: HFlags, AFlags, and BFlags. The HFlags
	field is 1 byte containing flag bits that pertain to the noncompressible basic header and
	the database object as a whole. The AFlags and BFlags fields are each single bytes containing
	flag bits that pertain to the (potentially compressed) attributes and body, respectively, in
	the object interior.
      </para>

      <table frame="all">
        <title>BRL-CAD Flags Structure</title>

	<tgroup cols="26" align="center">
	  <colspec colname="h1"/>
	  <colspec colname="h2"/>
	  <colspec colname="h3"/>
	  <colspec colname="h4"/>
	  <colspec colname="h5"/>
	  <colspec colname="h6"/>
	  <colspec colname="h7"/>
	  <colspec colname="h8"/>
	  <colspec colname="s1"/>
	  <colspec colname="a1"/>
	  <colspec colname="a2"/>
	  <colspec colname="a3"/>
	  <colspec colname="a4"/>
	  <colspec colname="a5"/>
	  <colspec colname="a6"/>
	  <colspec colname="a7"/>
	  <colspec colname="a8"/>
	  <colspec colname="s2"/>
	  <colspec colname="b1"/>
	  <colspec colname="b2"/>
	  <colspec colname="b3"/>
	  <colspec colname="b4"/>
	  <colspec colname="b5"/>
	  <colspec colname="b6"/>
	  <colspec colname="b7"/>
	  <colspec colname="b8"/>
	  <thead>
	    <row>
	      <entry namest="h1" nameend="h8" align="center">HFlags</entry>
	      <entry/>
	      <entry namest="a1" nameend="a8" align="center">AFlags</entry>
	      <entry/>
	      <entry namest="b1" nameend="b8" align="center">BFlags</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>7</entry>
	      <entry>6</entry>
	      <entry>5</entry>
	      <entry>4</entry>
	      <entry>3</entry>
	      <entry>2</entry>
	      <entry>1</entry>
	      <entry>0</entry>
	      <entry morerows="1"> </entry>
	      <entry>7</entry>
	      <entry>6</entry>
	      <entry>5</entry>
	      <entry>4</entry>
	      <entry>3</entry>
	      <entry>2</entry>
	      <entry>1</entry>
	      <entry>0</entry>
	      <entry morerows="1"> </entry>
	      <entry>7</entry>
	      <entry>6</entry>
	      <entry>5</entry>
	      <entry>4</entry>
	      <entry>3</entry>
	      <entry>2</entry>
	      <entry>1</entry>
	      <entry>0</entry>
	    </row>
	    <row>
	      <entry namest="h1" nameend="h2">Wid</entry>
	      <entry>N</entry>
	      <entry namest="h4" nameend="h5">Wid</entry>
	      <entry>r</entry>
	      <entry namest="h7" nameend="h8">DLI</entry>
	      <entry namest="a1" nameend="a2">Wid</entry>
	      <entry>P</entry>
	      <entry>r</entry>
	      <entry>r</entry>
	      <entry namest="a6" nameend="a8">ZZZ</entry>
	      <entry namest="b1" nameend="b2">Wid</entry>
	      <entry>P</entry>
	      <entry>r</entry>
	      <entry>r</entry>
	      <entry namest="b6" nameend="b8">ZZZ</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>

      <section>
        <title>Wid Flags</title>

	<para>
	  The length of an object or subelement in the database is recorded using an
	  unsigned integer. These are variable-width fields based on the magnitude of the
	  maximum number needed. The Wid bits specify the size of the unsigned integer
	  employed in each instance. There are four 2-bit width (Wid) flags: Object_Wid
	  and Name_Wid (stored in HFlags), Attribute_Wid (stored in AFlags), and Body_Wid
	  (stored in BFlags). The Wid fields are interpreted in this manner:
	</para>

	<table frame="all">
          <title>Wid Flag Definitions</title>

	  <tgroup cols="2" align="center">
	    <thead>
	      <row>
		<entry>Wid Bits</entry>
		<entry>Width (in bits) of Associated Length Fields</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>00</entry>
	      <entry>8</entry>
	    </row>
	    <row>
	      <entry>01</entry>
	      <entry>16</entry>
	    </row>
	    <row>
	      <entry>10</entry>
	      <entry>32</entry>
	    </row>
	    <row>
	      <entry>11</entry>
	      <entry>64</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>

      <para>
	The Object_Wid flag, at the high end of HFlags, encodes the
	width of the Object_Length field. The Name_Wid flag, in bits 3
	and 4 of HFlags, encodes the width of the Name_Length field
	(when the name element is present; see the N bit, shown
	later.). Attribute_Wid (or Body_Wid, as the case may be)
	encodes the width of the Attribute_Length field (when the
	Object_Attributes (or Object_Attributes) element is present.
	http://ftp.arl.mil/~mike/papers/brlcad5.0/newdb.html - bbitSee
	the P bit, below.)??????????.
      </para>

      <para>
	The rationale for allowing the width of the Object_Length field to be specified independently
	of the other widths is to save space on objects in which the values in many of the length
	fields nearly overflow the specified field width, so that their sum requires a wider field.
	For example, for four 255-byte interior fields, the corresponding length fields need be no
	more than 8 bits wide, so the choice Interior_Wid=00 suffices, but their combined length of
	1020 bytes would require Object_Wid=01. Because all of the length fields besides Object_Length
	must have the same width, the largest of the values stored in these length fields determines
	the value of Interior_Wid required. Both Object_Wid and Interior_Wid may vary from object to
	object. It is expected that the routines that write an object to the disk will use the
	narrowest width possible for each object.
      </para>

      </section>

      <section>
        <title>"r" Bits</title>

	<para>
	  The bits labled as "r" in all three flags are reserved for future design
	  work assigning additional optional fields in the object.
	</para>
      </section>

      <section>
        <title>HFlags - the DLI Flag</title>

	<para>
	  The DLI flag is a 2-bit flag that indicates whether the object is an Application
	  Data Object or a Database Layer Internal Object. The bits are interpreted as follows:
	</para>

	<table frame="all" pgwide="1">
          <title>DLI Flag Structure</title>

	  <tgroup cols="2" align="center">
	    <thead>
	      <row>
		<entry>DLI Bits</entry>
		<entry>Meaning</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>00</entry>
	      <entry align="left">
		Application Data Object
		<para>
		  The object contains application-specific data. N must be 1. A and B are
		  determined by what the application presents for storage in the object; both
		  may be 0 (empty Object_Interior).
		</para>
	      </entry>
	    </row>
	    <row>
	      <entry>01</entry>
	      <entry align="left">
		Database Layer Internal, Header Object
		<para>
		  A Header Object must be the first object encountered in the database. In
		  order to support direct concatenation of two existing databases into one new
		  database, additional header objects may appear elsewhere in the database The
		  header object has no object name, object attributes, or object body (e.g.,
		  N=0, A=0, B=0). Major_Type=RESERVED, Minor_Type=0.
		</para>
	      </entry>
	    </row>
	    <row>
	      <entry>10</entry>
	      <entry align="left">
		Database Layer Internal, Free Storage.
		<para>
		  Unused space in the database is kept using a special Free DB Storage object
		  that has no object name or object attributes. The object body is null-filled
		  and of the proper size for the storage to be represented. Like all other objects,
		  the total length of the object will be a multiple of 8 bytes. N=0, A=0, B=1.
		  Major_Type=RESERVED, Minor_Type=0.
		</para>
	      </entry>
	    </row>
	    <row>
	      <entry>11</entry>
	      <entry align="left">
		Database Layer Internal, Reserved
		<para>
		  This value is reserved for future use.
		</para>
	      </entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>

      <para>
	The DLI flag is not available to the higher database access layers.
      </para>
      <note>
	<para>
	  Implementation note: Before writing a new object into the database in a free area,
	  the library should read the object header from the database and confirm that the space
	  is indeed free. Similarly, additions to the end should be checked by ensuring that the
	  file hasn't been extended. In case the check fails, the database write should fail, the
	  user should be notified, and the internal library mode (not the operating system file
	  access permissions) should be changed over to read-only access so that no further attempts
	  to write will be issued. These checks will provide protection against two or more users
	  trying to modify the same database simultaneously and accidentally stepping on each
	  other. In the NFS world, file locking isn't a strong enough assurance.
	</para>
      </note>
      </section>

      <section>
        <title>HFlags - the N Bit</title>

	<para>
	  The "N" bit indicates whether the Name element (consisting of Name_Length and Object_Name
	  fields) is present (1) or absent (0) in the noncompressible basic header immediately following the
	  Object_Length field. The width of the Name_Length field is specified by the Name_Wid field.
	</para>
      </section>

      <section>
        <title>AFlags/BFlags - the P Bit</title>

	<para>
	  The ``P'' bit indicates whether the Attributes (or, alternatively, Body) element consisting
	  of Attribute_Length and Attribute_Data (or Body_Length and Body_Data) fields, is present (1)
	  or absent (0) in the Object_Interior.
	</para>
      </section>

      <section>
        <title>AFlags/BFlags - the ZZZ Flag</title>

	<para>
	  The 3-bit ``ZZZ'' flag indicates the compression, if any, of the object Attributes (or Body):
	</para>

	<table frame="all">
          <title>ZZZ Flag Definitions</title>

	  <tgroup cols="2" align="center">
	    <thead>
	      <row>
		<entry>ZZZ Bits</entry>
		<entry>Compression Algorithm</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>000</entry>
	      <entry>None</entry>
	    </row>
	    <row>
	      <entry>001</entry>
	      <entry>GNU GZIP</entry>
	    </row>
	    <row>
	      <entry>010</entry>
	      <entry>Burroughs-Wheeler</entry>
	    </row>
	    <row>
	      <entry>011</entry>
	      <entry>Reserved</entry>
	    </row>
	    <row>
	      <entry>100</entry>
	      <entry>Reserved</entry>
	    </row>
	    <row>
	      <entry>101</entry>
	      <entry>Reserved</entry>
	    </row>
	    <row>
	      <entry>110</entry>
	      <entry>Reserved</entry>
	    </row>
	    <row>
	      <entry>111</entry>
	      <entry>Reserved</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>
      </section>
    </section>

    <section>
      <title>Object Type</title>

      <para>
	The Object_Type element is always 16 bits wide, organized into two 8-bit-wide
	fields: the Major_Type and the Minor_Type.
      </para>
      <table frame="all">
        <title>Object_Type Element Structure</title>

	<tgroup cols="16" align="center">
	  <colspec colname="0"/>
	  <colspec colname="1"/>
	  <colspec colname="2"/>
	  <colspec colname="3"/>
	  <colspec colname="4"/>
	  <colspec colname="5"/>
	  <colspec colname="6"/>
	  <colspec colname="7"/>
	  <colspec colname="8"/>
	  <colspec colname="9"/>
	  <colspec colname="10"/>
	  <colspec colname="11"/>
	  <colspec colname="12"/>
	  <colspec colname="13"/>
	  <colspec colname="14"/>
	  <colspec colname="15"/>
	  <thead>
	    <row>
	      <entry namest="0" nameend="15" align="center">Object_Type</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry namest="0" nameend="7" align="center">Major Type</entry>
	      <entry namest="8" nameend="15" align="center">Minor Type</entry>
	    </row>
	    <row>
	      <entry>7</entry>
	      <entry>6</entry>
	      <entry>5</entry>
	      <entry>4</entry>
	      <entry>3</entry>
	      <entry>2</entry>
	      <entry>1</entry>
	      <entry>0</entry>
	      <entry>7</entry>
	      <entry>6</entry>
	      <entry>5</entry>
	      <entry>4</entry>
	      <entry>3</entry>
	      <entry>2</entry>
	      <entry>1</entry>
	      <entry>0</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>
      <para>
	Each different Major_Type value is assigned to a different class of database objects.
	The following values are defined in this specification:
      </para>
      <table frame="all">
        <title>Major_Type Values and Meanings</title>

	<tgroup cols="2" align="center">
	  <thead>
	    <row>
	      <entry>Value</entry>
	      <entry>Object Class</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>0</entry>
	      <entry>Reserved</entry>
	    </row>
	    <row>
	      <entry>1</entry>
	      <entry>BRL-CAD Nongeometry Objects</entry>
	    </row>
	    <row>
	      <entry>2</entry>
	      <entry>BRL-CAD Geometry Objects</entry>
	    </row>
	    <row>
	      <entry>3</entry>
	      <entry>Attribute-Only Objects</entry>
	    </row>
	    <row>
	      <entry>8</entry>
	      <entry>Experimental Binary Objects (Unrecorded Structure) (Minor Type Unspecified)</entry>
	    </row>
	    <row>
	      <entry>9</entry>
	      <entry>Uniform Array Binary Objects, (Type Described in Minor Type)</entry>
	    </row>
	    <row>
	      <entry>10</entry>
	      <entry>MIME_Typed Binary Objects (Attribute "mime_type" Describes Format)</entry>
	    </row>
	    <row>
	      <entry>16-31</entry>
	      <entry>Registered-Type Binary Objects</entry>
	    </row>
	    <row>
	      <entry>128</entry>
	      <entry>First Non-ARL Type Begins Here</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>
      <para>
	The remainder are available for extending the types of objects that may be stored in
	the database, allowing BRL-CAD users to extend the database for their own particular
	purposes far beyond what the "attribute" method permits.
      </para>

      <section>
        <title>Major_Type = 0: Reserved</title>

	<para>
	  Major Type 0 is illegal.  The rationale is to provide the library an opportunity to
	  detect incompletely filled in data structures.
	</para>
      </section>

      <section>
        <title>Major_Type = 1: BRL-CAD Nongeometry Objects</title>

	<para>
	  This class of objects is private to librt, concerning all nongeometric objects needed by
	  the library. For this Major_Type, the following Minor_Type values are defined:
	</para>
	<table frame="all">
          <title>Major_Type = 1:  Minor_Type Values and Meanings</title>

	  <tgroup cols="2" align="center">
	    <thead>
	    <row>
	      <entry>Minor_Type Value</entry>
	      <entry>Object Type</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>0</entry>
	      <entry>Reserved for sanity check</entry>
	    </row>
	    <row>
	      <entry>1</entry>
	      <entry>Combination</entry>
	    </row>
	    <row>
	      <entry>2</entry>
	      <entry>Grip (Nongeometric)</entry>
	    </row>
	    <row>
	      <entry>3</entry>
	      <entry>Joint (Nongeometric)</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>
      <para>
	All other values reserved for future expansion.
      </para>
      <para>
	?????Should "Grip" and "Joint" objects be of this type, or Major_Type = 2?
      </para>
      </section>

      <section>
        <title>Major_Type = 2: BRL-CAD Geometry Objects</title>

	<para>
	  This class of objects is private to librt, concerning all geometric objects needed
	  by the library. Typically, there will be one xxx/xxx.c module in librt for each minor type.
	  For this Major_Type, the following Minor_Type values are defined:
	</para>
	<table frame="all">
          <title>Major_Type = 2:  Minor_Type Values and Meanings</title>

	  <tgroup cols="2" align="center">
	    <thead>
	    <row>
	      <entry>Minor_Type Value</entry>
	      <entry>Object Type</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>0</entry>
	      <entry>Reserved for sanity check</entry>
	    </row>
	    <row>
	      <entry>1</entry>
	      <entry>Torus (TOR)</entry>
	    </row>
	    <row>
	      <entry>2</entry>
	      <entry>Truncated General Cone (TGC)</entry>
	    </row>
	    <row>
	      <entry>3</entry>
	      <entry>Ellipsoid (ELL)</entry>
	    </row>
	    <row>
	      <entry>4</entry>
	      <entry>Generalized ARB.  V + 7 vectors</entry>
	    </row>
	    <row>
	      <entry>5</entry>
	      <entry>ARS</entry>
	    </row>
	    <row>
	      <entry>6</entry>
	      <entry>Half-Space (HALF)</entry>
	    </row>
	    <row>
	      <entry>7</entry>
	      <entry>Right Elliptical Cylinder (REC) (TGC special case)</entry>
	    </row>
	    <row>
	      <entry>8</entry>
	      <entry>Polygonal facted object (Polysolid)</entry>
	    </row>
	    <row>
	      <entry>9</entry>
	      <entry>B-Spline Solid</entry>
	    </row>
	    <row>
	      <entry>10</entry>
	      <entry>Sphere (ELL Special Case)</entry>
	    </row>
	    <row>
	      <entry>11</entry>
	      <entry>n-Manifold Geometry (NMG) solid</entry>
	    </row>
	    <row>
	      <entry>12</entry>
	      <entry>Extruded bitmap solid</entry>
	    </row>
	    <row>
	      <entry>13</entry>
	      <entry>Volume (VOL)</entry>
	    </row>
	    <row>
	      <entry>14</entry>
	      <entry>ARB with N faces (ARBN)</entry>
	    </row>
	    <row>
	      <entry>15</entry>
	      <entry>Pipe (wire) solid (PIPE)</entry>
	    </row>
	    <row>
	      <entry>16</entry>
	      <entry>Particle system solid (PART)</entry>
	    </row>
	    <row>
	      <entry>17</entry>
	      <entry>Right Parabolic Cylinder (RPC)</entry>
	    </row>
	    <row>
	      <entry>18</entry>
	      <entry>Right Hyperbolic Cylinder (RHC)</entry>
	    </row>
	    <row>
	      <entry>19</entry>
	      <entry>Elliptical Paraboloid (EPA)</entry>
	    </row>
	    <row>
	      <entry>20</entry>
	      <entry>Elliptical Hyperboloid (EHY)</entry>
	    </row>
	    <row>
	      <entry>21</entry>
	      <entry>Elliptical Torus (ETO)</entry>
	    </row>
	    <row>
	      <entry>22</entry>
	      <entry>Grip Nongeometric</entry>
	    </row>
	    <row>
	      <entry>23</entry>
	      <entry>Joint Nongeometric</entry>
	    </row>
	    <row>
	      <entry>24</entry>
	      <entry>Height Field (HF)</entry>
	    </row>
	    <row>
	      <entry>25</entry>
	      <entry>Displacement Map (DSP)</entry>
	    </row>
	    <row>
	      <entry>26</entry>
	      <entry>2D Sketch (SKETCH)</entry>
	    </row>
	    <row>
	      <entry>27</entry>
	      <entry>Solid of extrusion (EXTRUDE)</entry>
	    </row>
	    <row>
	      <entry>28</entry>
	      <entry>Instanced submodel</entry>
	    </row>
	    <row>
	      <entry>29</entry>
	      <entry>FASTGEN4 CLINE solid</entry>
	    </row>
	    <row>
	      <entry>30</entry>
	      <entry>Bag o' triangles (BOT)</entry>
	    </row>
	    <row>
	      <entry>31</entry>
	      <entry>Combination Record</entry>
	    </row>
	    <row>
	      <entry>32</entry>
	      <entry>Experimental binary</entry>
	    </row>
	    <row>
	      <entry>33</entry>
	      <entry>Uniform-array binary</entry>
	    </row>
	    <row>
	      <entry>34</entry>
	      <entry>MIME-typed binary</entry>
	    </row>
	    <row>
	      <entry>35</entry>
	      <entry>Superquadratic ellipsoid</entry>
	    </row>
	    <row>
	      <entry>36</entry>
	      <entry>Metaball</entry>
	    </row>
	    <row>
	      <entry>37</entry>
	      <entry>Brep object</entry>
	    </row>
	    <row>
	      <entry>38</entry>
	      <entry>Hyperboloid of one sheet (HYP)</entry>
	    </row>
	    <row>
	      <entry>39</entry>
	      <entry>Constraint object</entry>
	    </row>
	    <row>
	      <entry>40</entry>
	      <entry>Solid of revolution</entry>
	    </row>
	    <row>
	      <entry>41</entry>
	      <entry>Collection of points (PNTS)</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>
      <para>
	The details of these Minor_Types are provided in Section IV.
      </para>
      </section>

      <section>
        <title>Major_Type = 3: Attribute-Only Objects</title>

	<para>
	  This type of object stores only attributes in the object interior section; it has no
	  object body elements.
	</para>
	<para>
	  For example, if several objects need to have the same shader parameters, it would be
	  possible to create one attribute-only object to hold these common attributes and serve as a
	  simple form of "macro". Objects that needed to share these attributes could all reference the
	  same attribute object. If the attribute object is altered, then all of the objects that
	  reference it would be updated together. Without this capability, the user would have to
	  update each element individually to alter the attributes.
	</para>
	<para>
	  Conventions will have to be established regarding which attributes of an attribute-only
	  object will be used when a macro reference is performed. For example, rt shaders will
	  only be interested in the value of the "oshader=" attribute, while librt's tree-walker
	  might also be interested in the "rgb=", "giftmater=", "nsn=", "material=", and "los="
	  attributes (assuming that a convention was developed so that a combination could
	  macro-reference an attribute-only object too).
	</para>
	<para>
	  An attribute-only object may not have an object body; thus, flag bit B must always be
	  zero for this type of object.
	</para>
	<para>
	  As used by the rt family of applications codes, these attribute-only objects will
	  contain "macros" for shaders. The shader name and its parameters shall be encoded as a
	  single ASCII string, which is the value of the "oshader=" attribute. An rt shader named
	  "macro" (or equivalent) would take a single parameter "obj=", which would specify the
	  name of the attribute-only object in the database from which the actual shader and
	  shader parameter information would be extracted.
	</para>
	<para>
	  There will be one attribute-only object with a reserved object name of "_GLOBAL" that
	  will be used to contain various kinds of states that are global to the entire ".g" database
	  and that had previously been found in the database header itself. There will be the
	  following BRL-CAD-specific attributes whose meaning is predefined for the _GLOBAL object:
	  <itemizedlist>
	    <listitem>
	      <para>
		title = The database "title" string previously found in the database header.
	      </para>
	    </listitem>
	    <listitem>
	      <para>
		units = The most recent editing units, specified as an ASCII string with a
		floating point conversion factor. For example, the conversion factor for inches
		to millimeters would be 25.4.
	      </para>
	    </listitem>
	    <listitem>
	      <para>
		regionid_colortable = A string that contains a collection of all the information
		previously found in "struct material_rec ID_MATERIAL" records. Exact encoding yet
		to be determined; it's a collection of integer 5-tuples of the form:
		{low, high, r, g, b}.
	      </para>
	    </listitem>
	  </itemizedlist>
	</para>
	<para>
	  In addition, the "comment=" attribute of the "_GLOBAL" object may be used to store
	  human-readable remarks about the database that are not more properly associated with a
	  specific database item. These might include remarks about data sources, model evolution,
	  security classification, and release restrictions. In the absense of some outboard
	  revision-control system, this might also be a place to record modification history,
	  although such use is discouraged.
	</para>
      </section>

      <section>
        <title>Bulk Binary Objects (Major_Types 8-31)</title>

	<para>
	  This class of objects contains various "bulk" binary data that might otherwise have
	  been placed in auxiliary files.
	</para>
	<para>
	  MGED and standalone commands must be built to store/extract these opaque?? binary
	  objects between a ".g" file and stdin/stdout/auxiliary files. A user might want to use
	  those same MGED commands to store/extract the binary object body of any object for external
	  processing. An easy example to imagine is the importing and exporting of texture maps for
	  external processing, but the same commands could be used for importing and exporting
	  solid parameters in their external binary form.
	</para>
	<para>
	  These objects may be referenced in combination nodes, for organizational purposes, but
	  they cannot be drawn in MGED or raytraced, and doing so would result in a warning message
	  being printed by the tree walker as that arc is traversed. This class may be used by all
	  applications and layers.
	</para>
	<para>
	  The data's purpose may be placed in the "purpose=" attribute. (????????Need a
	  table/registry of presently known values for this attribute.)
	</para>
	<para>
	  Routines that retrieve bulk binary objects should check the minor type and the
	  "purpose=" attribute and send a warning message in the event of a mismatch, but
	  best-effort processing of the object should continue. This will permit some degree
	  of error checking, which should benefit novice users without standing in the way of
	  "creatively" reusing one set of data, (e.g., using one array of values as both a height
	  field and a bwtexture). This allows common data perversion practices, such as interpreting
	  an array of floats as an array of bytes, to continue.
	</para>
	<para>
	  Each application will need to have its own syntax for the user to specify whether the data
	  source is an outboard file or a raw-binary object. For example, the current RT sh_texture
	  module uses the keyword file="name" to indicate an outboard file; that might be supplemented
	  with an additional obj="name" possibility for retrieving from an inboard raw-binary object.
	</para>

	<section>
          <title>Major_Type = 8: Experimental Binary Objects</title>

	  <para>
	    This class of objects contains bulk binary data and is intended for experimental
	    use by applications developers. Each time a database containing objects of this type
	    is opened, BRL-CAD will issue a user-visible warning. Production software and databases
	    should not use these objects. Developers should obtain registered 16-bit object types
	    from the website in order to avoid collisions with other applications.
	  </para>
	</section>

	<section>
          <title>Major_Type = 9: Uniform Array Binary Objects</title>

	  <para>
	    This class of objects contain various "bulk" binary data that might otherwise have
	    been placed in an auxiliary file.
	  </para>
	  <para>
	    Point of Discussion?????Has ramifications... we have to implement type advising, so
	    that applications that use these data can compare the type provided in the minor
	    type code with the type that they're expecting and advise the user (with a warning
	    message) that there is a potential type mismatch.
	  </para>
	  <table frame="all">
            <title>Uniform Array Binary Objects Minor_Type Structure</title>

	    <tgroup cols="8" align="center">
	      <colspec colname="h1"/>
	      <colspec colname="h2"/>
	      <colspec colname="h3"/>
	      <colspec colname="h4"/>
	      <colspec colname="h5"/>
	      <colspec colname="h6"/>
	      <colspec colname="h7"/>
	      <colspec colname="h8"/>
	      <thead>
		<row>
		  <entry namest="h1" nameend="h8" align="center">Minor_Type</entry>
		</row>
	      </thead>
	      <tbody>
		<row>
		  <entry>7</entry>
		  <entry>6</entry>
		  <entry>5</entry>
		  <entry>4</entry>
		  <entry>3</entry>
		  <entry>2</entry>
		  <entry>1</entry>
		  <entry>0</entry>
		</row>
		<row>
		  <entry>r</entry>
		  <entry>r</entry>
		  <entry namest="h3" nameend="h4">Wid</entry>
		  <entry>S</entry>
		  <entry namest="h6" nameend="h8">Atom</entry>
		</row>
	      </tbody>
	    </tgroup>
	  </table>
	  <para>
	    The 3-bit ``Atom'' flag indicates the fundamental data type of the atomic elements
	    in the array according to the following scheme:
	  </para>
	  <table frame="all">
            <title>Atom Flag Definitions</title>

	    <tgroup cols="2" align="center">
	      <thead>
		<row>
		  <entry>Atom Bits</entry>
		  <entry>Data Type</entry>
		</row>
	      </thead>
	      <tbody>
		<row>
		  <entry>000</entry>
		  <entry>Reserved for sanity check</entry>
		</row>
		<row>
		  <entry>001</entry>
		  <entry>Reserved</entry>
		</row>
		<row>
		  <entry>010</entry>
		  <entry>float (IEEE, network order)</entry>
		</row>
		<row>
		  <entry>011</entry>
		  <entry>double (IEEE, network order)</entry>
		</row>
		<row>
		  <entry>100</entry>
		  <entry>8-bit int</entry>
		</row>
		<row>
		  <entry>101</entry>
		  <entry>16-bit int</entry>
		</row>
		<row>
		  <entry>110</entry>
		  <entry>32-bit int</entry>
		</row>
		<row>
		  <entry>111</entry>
		  <entry>64-bit int</entry>
		</row>
	      </tbody>
	    </tgroup>
	  </table>
	  <para>
	    The ``S'' bit indicates whether an integer type is signed (1) or unsigned (0).
	    Floats and doubles (i.e., atomic types with the highest atom bit equal to 0) are
	    explicitly signed, so they will have the ``S'' bit equal to 1. (The bit patterns
	    corresponding to unsigned floats and doubles are reserved for possible other use.)
	  </para>
	  <para>
	    The 2-bit ``Wid'' flag specifies the length (in atomic elements) of the array elements:
	  </para>
	  <table frame="all">
            <title>Wid Flag Definitions</title>
	    
	    <tgroup cols="2" align="center">
	      <thead>
		<row>
		  <entry>Wid Bits</entry>
		  <entry>Atoms per Array Element</entry>
		</row>
	      </thead>
	      <tbody>
		<row>
		  <entry>00</entry>
		  <entry>1</entry>
		</row>
		<row>
		  <entry>01</entry>
		  <entry>2</entry>
		</row>
		<row>
		  <entry>10</entry>
		  <entry>3</entry>
		</row>
		<row>
		  <entry>11</entry>
		  <entry>4</entry>
		</row>
	      </tbody>
	    </tgroup>
	  </table>
	  <para>
	    The remaining Minor_Type bits ``r'' are reserved for the design committee to use for
	    other purposes, possibly including extensions of the ``Atom'' and/or ``Wid'' flags.
	  </para>
	  <para>
	    As examples, data in PIX(5) format, which might be used for a texture map, would 
	    have Minor_Type ``0010 0100'', indicating a triple of unsigned char, and CMYK data 
	    might be stored with Minor_Type ``0011 1011'', indicating a quadruple of doubles.
	  </para>
	  <para>
	    The data's purpose (e.g., height field, texture, bump,
	    displacement, etc.) may be placed in the "purpose="
	    attribute. ????? Point of Discussion ???(Need a
	    table/registry of presently known values for this
	    attribute.)
	  </para>
	</section>

	<section>
          <title>Major_Type = 10: MIME-Typed Binary Objects</title>
	  
	  <para>
	    This class of objects contains data, the format of which is specified in the 
	    attribute "mime_type". The Minor_Type of these objects should always be zero.
	  </para>
	</section>

	<section>
          <title>Major_Type = 16-31: Registered-Type Binary Objects</title>
	  
	  <para>
	    This class of objects contains application-specific bulk
	    binary data and is intended for use in production software
	    and databases. Developers can obtain registered 16-bit
	    object types from the website to identify these
	    objects. The data's purpose, (e.g., height field, texture,
	    bump, displacement, etc.) may be placed in the "purpose="
	    attribute. (Need a table/registry of presently known
	    values for this attribute).
	  </para>
	</section>
      </section>
      
      <section>
        <title>Major_Type = 255: Database Layer Internal Objects</title>
	
	<para>
	  A Minor_Type of 1 indicates that this is a contiguous block of free storage.
	</para>
	<para>
	  A Minor_Type of 2 indicates that this is a database header.
	</para>
      </section>

    </section>

    <section>
      <title>Object Length</title>
      
      <para>
	The Object Length specifies the number of 8-byte chunks used to store an object. This includes all bytes 
	from Magic1 through Magic2, inclusive.
      </para>
    </section>

    <section>
      <title>Object Name</title>
      
      <para>
	The Object_Name element is a string that holds a name unique
	to that object and drawn from a name space that is global to
	the database. The Object_Name element is mandatory for all
	allocated storage in the database. Database free-space
	managment objects are the only objects for which the
	Object_Name element is optional.
      </para>
      <para>
	The name is specified in 8-bit ASCII. There is no support for UNICODE. The name is null-terminated, and the 
	null byte is included in Name_Length.
      </para>
      <para>
	See the section on DLI flags. In the case of Free objects, the name is not retained. Undeleted objects have 
	a different DLI flag code.
      </para>
    </section>

    <section>
      <title>Object Attributes</title>
      
      <para>
	An object may optionally have an Object_Attributes element, which stores an association list
	<literallayout class="normal">
aname1=value1, aname2=value2, ..., anameN=valueN
	</literallayout>
	binding attributes to values.
      </para>
      <para>
	These are ASCII strings of unlimited length. These attributes are intended for direct use by programs. 
	There will be a WWW registry of attribute names presently in use to prevent two application developers 
	from using the same attribute_name for different purposes.
      </para>
      <para>
	For attribute names and attribute values, The decision was taken to support 8-bit ASCII only. The 
	on-disk encoding of this will simply be:
	<literallayout class="normal">
aname1 NULL value1 NULL ... anameN NULL valueN NULL NULL
	</literallayout>
	where NULL represents a byte with all bits zero. The NULL in place of anameN+1 signals the end of the 
	attribute data, simplifying the job of the reader. 
      </para>
      <para>
	Every object in the database may have zero or more attributes attached to it; the meaning of these attributes 
	will vary depending on which application or library processes them.
      </para>
      <para>
	There are several aname conventions that all BRL-CAD applications are expected to respect. There will be a 
	WWW extendable registry of "in-use" anames, so that independent applications developers may select aname 
	strings for their own use without fear of name conflicts later. The initial registry would include:
	<itemizedlist>
	  <listitem>
	    <para>
	      comment = Every object may optionally have a comment that contains a string of an arbitrary number of 
	      newline-terminated lines of text. These are strings for use by humans only. None of the BRL-CAD software
	      may parse or interpret these strings other than to print them and edit them when requested by the user. 
	      They are provided for the modeler to place notes in.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      nsn = The American National Stock Number (NSN) for this part, when known.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      material = The format of this string is not currently defined as there are conflicting naming/coding 
	      conventions employed by the various standards organizations (e.g., ISO, ASME, etc.).
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      region = For combinations, indicates this combination is a region. Boolean.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      inherit = For combinations, indicates whether attributes from lower combinations in tree will replace 
	      higher ones. Boolean, default=0.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      oshader = For combinations, read by the "rt" program, optical shader name and parameter string (separated 
	      from each other by white space). Meaningful only at or above a region node, and only on a combination, or 
	      in an attribute-only "macro".
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      rgb = For combinations, when present indicates optical rgb color is specified.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      region_id = For regions, GIFT compatability. Integer.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      giftmater = For regions, GIFT compatability. Integer. (Point of Discussion?????Should we use negative values for 
	      air codes, positive for nonair, so we can eliminate air codes?)
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      aircode = For regions, air code. Integer. 0 is the same as attribute not specified. (Point of 
	      Discussion?????Possibly eliminated in favor of negative giftmater values).
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      los = For regions, GIFT compatability. Integer.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      component = For regions, the name of the MUVES component containing this object.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      rlist = The proposed BRL-CAD "replacement list" field would be stored on a binary-block attribute 
	      ("rlist="). [deferred implementation]
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      macro = If present, specifies name of an attribute-only object to be consulted for additional attribute values.
	    </para>
	  </listitem>
	</itemizedlist>

	All other attributes, from whatever source, would be stored similarly, including application-specific and 
	end-user-created attributes.
      </para>
    </section>
    <section>
      <title>Object Body</title>
      
      <para>
	The contents of the Object Body are opaque?? to the databaase layer. The contents of this element are interpreted 
	based upon the Object_Type. The Object_Body is not constrained to start on a chunk boundary.
      </para>
    </section>

    <section>
      <title>Padding and Length Rounding</title>
      
      <para>
	The minimal object is a Free object (with no name) 8 bytes long:
	<literallayout class="normal">
     Magic1 (1byte) 
     HFlags = 000xxxxx (1 byte)  
     AFlags = 0000xx00 (1 byte) 
     BFlags = 0000xx00 (1 byte) 
     ObjType = Free (2 bytes) 
     ObjLen = 7 (1 byte) 
     Magic2 (1 byte).
	</literallayout>
	This is why we have chosen the 8-bit size for our chunks. Pad bytes are inserted as necessary in the Object Footer 
	immediately before the second magic number so that the final byte of the object is the Magic2 byte. The pad bytes are 
	not counted as part of the Body_Length, but are counted as part of the Object_Length.
      </para>
      <para>
	The minimal valid object is thus the following Free object:
	<literallayout class="normal">
Magic1 (1byte) 
HFlags = 00000010 (1 byte), Wid=00, N=0, DLI=02 
IFlags????? = 00000000 (1 byte), Wid=00, A=0, B=0, ZZZ=000 
Object_Type = RESERVED (2 bytes) 
Object_Length = 1 (1 byte) 
Pad (1byte) 
Magic2 (1 byte).
	</literallayout>
      </para>
      <para>
	The header of the database will always look like this:
	<literallayout class="normal">
Magic1 (1byte) 
HFlags = 000xxx01 (1 byte), Wid=00, N=0, DLI=01 
IFlags????? = 0000x000 (1 byte), Wid=00, A=0, B=0, ZZZ=000 
Object_Type = RESERVED (2 bytes) 
Object_Length = 1 (1 byte) 
Pad (1byte) 
Magic2 (1 byte)
The hex and ASCII dump of this object would look something this:
  
76 01 00 00 00 01 00 35 |v......5|
	</literallayout>
      </para>
      <para>
	The minimal valid allocated database storage object (with an Object_Name, no Object_Attributes or Object_Body) would thus be:
	<literallayout class="normal">
Magic1 (1byte) 
HFlags = 001xxxxx (1 byte), Wid=00, N=1, DLI=00 
IFlags ?????= 0000xxxx (1 byte), Wid=00, A=0, B=0, ZZZ=000 
Object_Type = OPAQUE?????_BINARY (2 bytes) 
Object_Length = 8 (1 byte) 
Name_Length = 2 (1 byte) 
Object Name (1 character + null byte) (2 bytes) 
Pad (6 bytes) 
Magic2 (1 byte).
	</literallayout>
      </para>
      <para>
	Without the padding, this (rather useless) object would be 10 bytes long. Given the rounding requirements, it is clear that all allocated storage objects in the database must be at least 16 bytes long. A database object with a minimal Object_Body would need 12 bytes, which would need to be padded out to 16 bytes as well:
	<literallayout class="normal">
Magic1 (1 byte) 
HFlags = 001xxxxx (1 byte) 
IFlags???? = 00x1xxxx (1 byte) 
Object Type (2 bytes) 
Object Length = 16 (1 byte) 
Name Length = 2 (1 byte) 
Object Name (1 character + null byte) (2 bytes) 
Body Length = 1 (1 byte) 
Body Data (1 byte) 
Pad (4 bytes) 
Magic2 (1 byte).
	</literallayout>
	
      </para>
      <para>
	<literallayout class="normal">
	</literallayout>
      </para>
      <para>
	<literallayout class="normal">
	</literallayout>
      </para>
      <para>
	<literallayout class="normal">
	</literallayout>
      </para>

  </section>



  <section>
    <title>How Objects Are Grouped into a Database</title>
    
    <para>
      
    </para>
  </section>

  <section>
    <title>Details of BRL-CAD-Specific Nongeometric Database Object Types</title>
    
    <para>
      
    </para>
  </section>

  <section>
    <title>Details of BRL-CAD-Specific Geometric Database Object Types</title>
    
    <para>
      
    </para>
  </section>

  <section>
    <title>Extensions for Deferred Implementation</title>
    
    <para>
      
    </para>
  </section>

  <section>
    <title>Community Feedback on the Proposal</title>
    
    <para>
      
    </para>
  </section>

  <section>
    <title>Database Library Application Programming Interface (API)</title>
    
    <para>
      
    </para>
  </section>
</section>
</article>
