Difference between revisions of "Filling Out the Table Binary Data Structure"

From The SBN Wiki
Jump to navigation Jump to search
(Update for Release 1.0)
Line 1: Line 1:
 
The '''''<Table_Binary>''''' class contains the data structure definition for a binary table.  Each row in the table has the same structure, defined in a ''Record_binary'' class.  Records are themselves composed of scalar fields, or sub-records called "grouped fields".  Use it if your data cannot be reasonably archived as fixed-width character tables because of data volume.
 
The '''''<Table_Binary>''''' class contains the data structure definition for a binary table.  Each row in the table has the same structure, defined in a ''Record_binary'' class.  Records are themselves composed of scalar fields, or sub-records called "grouped fields".  Use it if your data cannot be reasonably archived as fixed-width character tables because of data volume.
  
:{| class="wikitable" style="background-color: khaki"
+
:{| class="wikitable" style="background-color: yellow"
 
|  
 
|  
 
: '''''N.B. SBN Data Preparers:''''' Our users and our reviewers have a '''very''' strong dislike for binary tables because of the difficult and subtle issues involved in using the data, and especially in using binary data from multiple sources.  If you don't have at least three good ''archival'' reasons for using binary tables, don't do it.  If you do anyway there is a very high probability that you will be directed to convert them to character tables by the peer review panel.
 
: '''''N.B. SBN Data Preparers:''''' Our users and our reviewers have a '''very''' strong dislike for binary tables because of the difficult and subtle issues involved in using the data, and especially in using binary data from multiple sources.  If you don't have at least three good ''archival'' reasons for using binary tables, don't do it.  If you do anyway there is a very high probability that you will be directed to convert them to character tables by the peer review panel.
Line 7: Line 7:
 
: Also, if you supply data in a binary table format, you should also plan to supply a sample of a few records that have been translated to an ASCII format, for end-users to reference when they are trying to verify that they are reading the data correctly.
 
: Also, if you supply data in a binary table format, you should also plan to supply a sample of a few records that have been translated to an ASCII format, for end-users to reference when they are trying to verify that they are reading the data correctly.
  
: When in doubt, talk to your PDS consultant.
+
: When in doubt, talk to your SBN data consultant.
 
|}
 
|}
  
Line 41: Line 41:
 
''REQUIRED''
 
''REQUIRED''
  
This is the total number of records in the table.  Records in binaries tables do not usually have record delimiters.
+
This is the total number of records in the table.  Records in binaries tables do not usually have record delimiters. On the rare occasions when they do, they are documented as a record field.
 
 
== <encoding_type> ==
 
 
 
''REQUIRED''
 
 
 
This must have the value '''Binary'''.
 
  
 
== <description> ==
 
== <description> ==
Line 59: Line 53:
 
''OPTIONAL''
 
''OPTIONAL''
  
If this ''Table_Binary'' contains records which are uniformly spaced in some dimension (time, wavelength, distance, etc.), you can use this class to define that dimension and interval rather than including an additional field in each row to hold the value explicitly.
+
If this ''Table_Binary'' contains records which are uniformly spaced in some dimension (time, wavelength, distance, etc.), you can use this class to define that dimension and interval rather than including an additional field in each row to hold the value explicitly. The details are on the [[Filling Out the Uniformly Sampled Class]] page.
  
'''Note:''' There are certain types of data where this class can prevent a very large data file from increasing in size by %50.  Such tables are predominantly used by software, not human readers scanning them by eye.  For SBN data, our users generally prefer to see the additional column. So unless the two conditions above apply to your data, you should include the extra column.
+
Here's a quick summary of what's in that class.  All but ''sampling_parameter_scale'' are required:
 +
* sampling_parameter_name
 +
* sampling_parameter_interval
 +
* sampling_parameter_unit
 +
* first_sampling_parameter
 +
* last_sampling_parameter
 +
* sampling_parameter_scale
  
=== <sampling_parameter_name> ===
+
== <Record_Binary> ==
  
 
''REQUIRED''
 
''REQUIRED''
  
The name of the dimension of sampling (wavelength, time, etc.)
+
This class describes the structure of one complete record in the table.
  
=== <sampling_parameter_interval> ===
+
=== <fields> ===
  
 
''REQUIRED''
 
''REQUIRED''
  
Distance between records in units of the sampling parameterSo if you're sampling in time, the interval might be 100 milliseconds, for example.
+
The number of ''Field'' classes directly under (that is, in the first nesting level of) the ''Record'' classDo '''''not''''' count ''Field'' classes nested under ''Group_Field'' classes.
  
=== <sampling_parameter_unit> ===
+
If your ''Record'' contains only one or more ''Group_Field'' classes, this will have a value of zero.
  
''REQUIRED''
+
=== <groups> ===
 
 
The unit associated with the ''sampling_parameter_interval''.
 
 
 
=== <first_sampling_parameter_value> ===
 
  
 
''REQUIRED''
 
''REQUIRED''
  
The value of the sampling parameter at the point where the data of the first record were recorded.
+
The number of ''Group_Field'' classes directly under (that is, in the first nesting level of) the Record class.  Do '''''not''''' count ''Group_Field'' classes under other ''Group_Field'' classes.
 
 
=== <last_sampling_parameter_value> ===
 
  
''REQUIRED''
+
If your ''Record'' contains only one or more ''Field'' classes, this will have a value of zero.
 
 
 
 
The value of the sampling parameter at the point where the data of the last record were recorded.
 
 
 
=== <sampling_parameter_scale> ===
 
 
 
''OPTIONAL''
 
 
 
This is actually the type of the scale.  It must be one of the standard values '''Exponential''', '''Linear''', or '''Logarithmic'''.
 
 
 
 
 
== <Record_Binary> ==
 
 
 
''REQUIRED''
 
 
 
This class describes the structure of one complete record in the table.
 
 
 
=== <fields> ===
 
 
 
''REQUIRED''
 
 
 
The number of fields in the ''Record''.
 
 
 
{| class="wikitable" style="backgound-color: thistle
 
| '''''Note:''''' ''This is some controversy about what this value should be when ''Group Fields'' are present.  For the time being, use the data dictionary definition - the number of fields in the record is the total number of scalar values in the record; so it is the sum of all ''Field'' definitions in the record, and the number of ''Field'' definitions in each ''Group Field'' multiplied by the ''repetitions'' value of that group.''
 
|}
 
  
 
=== <record_length> ===
 
=== <record_length> ===
Line 121: Line 89:
 
''REQUIRED''
 
''REQUIRED''
  
The total length of the record, including all fields, all repetitions of group fields, any space between fields, and the record delimiter.  You must specify a unit of bytes for this value:
+
The total length of the record, including all fields, all repetitions of group fields, and any fill space between fields.  You must specify a unit of bytes for this value:
 
<pre>
 
<pre>
 
     <record_length unit="byte">1234</record_length>
 
     <record_length unit="byte">1234</record_length>
 
</pre>
 
</pre>
  
:{| class="wikitable" style="background-color: khaki"
+
----
|
 
: Records are composed of ''Fields'' and ''Group Fields''.  A ''Record'' must have at least one of those, and can have an arbitrary number of them, in any order (that is, you can have ''Fields'' and ''Group Fields'' interspersed).
 
  
: There are currently serious arguments  underway associated with using ''Group Fields'', in particular when attempting to determine the correct value for the required ''&lt;fields&gt;'' attribute, above.  Because of this, SBN data preparers should not use ''Group Fields'' until the disagreements have been solved. ''Group Fields'' are '''''never''''' necessary - they are a notational convenience to save writing out large numbers of similar ''Field'' definitions.
+
=== A Note about '''Fields''' and '''Group_Fields''' ===
 +
 
 +
Records are composed of ''Fields'' and ''Group Fields''. A ''Record'' must have at least one of those (either will do), and can have an arbitrary number of them, in any order (that is, you can have ''Fields'' and ''Group Fields'' interspersed). Note, however, that ''Group Fields'' are '''''never''''' necessary - they are a notational convenience to save writing out large numbers of essentially identical ''Field'' definitions.
 +
 
 +
{| class="wikitable" style="background-color: yellow"
 +
|
 +
: SBN data preparers should '''''never''''' use a ''Group_Field'' where a reasonable set of ''Fields'' will do. In particular, no ''Group_Field'' should have a ''&lt;repetitions&gt;'' count of less than 2 in any SBN data product. If you have data that seem like they should be an exception, please contact your SBN data consultant with the details.
 
|}
 
|}
 +
 +
----
  
 
=== &lt;Field_Binary&gt; ===
 
=== &lt;Field_Binary&gt; ===
 +
 +
''OPTIONAL''
  
 
The class defines a single scalar field.
 
The class defines a single scalar field.
Line 147: Line 123:
 
''OPTIONAL''
 
''OPTIONAL''
  
This is the sequential number of the ''Field'' definition. This is poorly defined when ''Group Fields'' are present, and should probably not be used at all in that case.  The ''field_number'' is intended to be a help to human readers trying to map field definitions to columns in a print-out of the ''Table''.  
+
This is the sequential number of the ''Field'' definition. For SBN data products, the ''field_number'' is intended to be a help to human readers trying to map field definitions to columns in a print-out of the ''Table''.
 +
 
 +
{| class="wikitable" style="background-color: yellow"
 +
|
 +
: SBN will generally require ''&lt;field_number&gt;'' be used in all flat tables (i.e., those without ''Group_Fields'').
 +
 
 +
: The ''Standards Reference'' lays out rules for using the ''field_number'' in cases where there are ''Group_Fields'' present which can be useful in programmatic contexts, but not so much in the visual-inspection case. For these tables SBN considers ''field_number'' and ''group_number'' to be optional.
 +
|}
  
 
==== &lt;field_location&gt; ====
 
==== &lt;field_location&gt; ====
Line 177: Line 160:
 
''OPTIONAL''
 
''OPTIONAL''
  
The value of this attribute is a string representing the read/print format for the data in the field, using a subset of the POSIX print conventions.
+
The value of this attribute is a string representing the optimal print format for the data in the field, using a subset of the POSIX print conventions defined in the ''Standards Reference'', and also described on the [[PDS4 field format Conventions]] page.
 
 
{| class="wikitable" style="background-color: thistle"
 
|'''''Note:''''' ''The syntax of the content of this field is poorly defined in the current data dictionary.
 
|}
 
 
 
The SBN has defined a subset of the POSIX standard for use in SBN data sets on the [[PDS4_field_format_Conventions]] page.
 
  
{| class="wikitable" style="background-color: khaki"
+
{| class="wikitable" style="background-color: yellow"
 
| SBN will require that this attribute be present in '''all''' ''Field'' definitions.  It is used for validation of the ''Table'' contents.
 
| SBN will require that this attribute be present in '''all''' ''Field'' definitions.  It is used for validation of the ''Table'' contents.
 
|}
 
|}
Line 201: Line 178:
 
''OPTIONAL''
 
''OPTIONAL''
  
If the data in this field are scaled, this attribute should contain the value the data must be multiplied by to get back to the original value. Scaling factors are applied prior to adding any offset.
+
f the observational values of this field were scaled prior to writing, this attribute should contain the value the data must be multiplied by to get back to the original value. Scaling factors are applied prior to adding any offset.
  
 
==== &lt;value_offset&gt; ====
 
==== &lt;value_offset&gt; ====
Line 207: Line 184:
 
''OPTIONAL''
 
''OPTIONAL''
  
If the values in the field have been shifted by an offset, this attribute should contain the value that must be added to each field value to get back to the original value. Offsets and added ''after'' the scaling factor, if any.
+
f the observational values of the field were shifted by an offset prior to writing, this attribute should contain the value that must be added to each field value to get back to the original value. Offsets and added after the scaling factor, if any, is applied.
  
 
==== &lt;description&gt; ====
 
==== &lt;description&gt; ====
Line 228: Line 205:
 
* ''unknown_constant''
 
* ''unknown_constant''
 
* ''not_applicable_constant''
 
* ''not_applicable_constant''
 +
* ''valid_maximum''
 +
* ''high_instrument_saturation''
 +
* ''high_representation_saturation''
 +
* ''valid_minimum''
 +
* ''low_instrument_saturation''
 +
* ''low_representation_saturation''
  
 
==== &lt;Field_Statistics&gt; ====
 
==== &lt;Field_Statistics&gt; ====
Line 249: Line 232:
  
 
=== &lt;Group_Field_Binary&gt; ===
 
=== &lt;Group_Field_Binary&gt; ===
 +
 +
''OPTIONAL''
  
 
This class defines a set of ''Fields'' and ''Group Fields'' that repeats a given number of times in each record.  ''Group Fields'' may be nested.
 
This class defines a set of ''Fields'' and ''Group Fields'' that repeats a given number of times in each record.  ''Group Fields'' may be nested.
  
'''''Note:''''' Unless you have three good reasons, don't use ''Group Fields'' in for SBN data.
+
{| class="wikitable" style="background-color: yellow"
 +
| '''''Note:''''' Unless you have three good reasons, don't use ''Group Fields'' in SBN data products.
 +
|}
 +
 
 +
==== &lt;group_number&gt; ====
 +
 
 +
''OPTIONAL''
 +
 
 +
Analogous to ''field_number'' for scalar fields, this is a sequential number useful for referencing ''Group_Field'' classes at a single nesting level of a complex ''Record'' definition.
  
 
==== &lt;repetitions&gt; ====
 
==== &lt;repetitions&gt; ====
Line 260: Line 253:
 
The number of times the complete set of ''Fields'' and ''Group Fields'' comprising the ''&lt;Group_Field_Binary&gt;'' repeats.
 
The number of times the complete set of ''Fields'' and ''Group Fields'' comprising the ''&lt;Group_Field_Binary&gt;'' repeats.
  
{| class="wikitable" style="background-color: thistle"
+
{| class="wikitable" style="background-color: yellow"
 
| '''''Note:''''' ''The minimum value for this field listed in the data dictionary is one, but no product will pass SBN review unless this value is at least two.''
 
| '''''Note:''''' ''The minimum value for this field listed in the data dictionary is one, but no product will pass SBN review unless this value is at least two.''
 
|}
 
|}
 
  
 
==== &lt;fields&gt; ====
 
==== &lt;fields&gt; ====
Line 269: Line 261:
 
''REQUIRED''
 
''REQUIRED''
  
This is not well-defined, and is the subject of debate as I type this.   
+
The count of Field classes directly under (i.e., at the first nesting level below) the Group_Field definitionThis will be zero if the group contains no scalar Fields.
  
{| class="wikitable" style="background-color: thistle"
+
==== &lt;groups&gt; ====
  
| '''''Note:''''' ''The current data dictionary definition of this value is actually the definition for ''Record_Binary'', which is at the least grammatically problematic.''
+
''REQUIRED''
|}
+
 
 +
The count of Group_Field classes directly under (i.e., at the first nesting level below( the present Group_Field definition.  This will be zero of the group contains no nested Group_Field classes.
  
 
==== &lt;group_location&gt; ====
 
==== &lt;group_location&gt; ====
Line 284: Line 277:
 
     <group_location unit="byte">1</group_location>
 
     <group_location unit="byte">1</group_location>
 
</pre>
 
</pre>
 +
 +
This value should be set bearing in mind that it will be used as the base offset for locating each repetition of the group. In other words, the location of the start of the first repetition of the group is group_location + 0*group_length; the location of the start of the second repetition of the group is group_location + 1*group_length, and so on.
  
 
==== &lt;Fields&gt; and Nested &lt;Group_Fields&gt; ====
 
==== &lt;Fields&gt; and Nested &lt;Group_Fields&gt; ====
  
 
As in the ''Record'', the ''Group'' may contain either ''Fields'', or ''Group_Fields'', or both intermixed.  ''Group_Fields'' may be nested arbitrarily deeply.  The requirement for these data structure classes inside a ''&lt;Group_Field_Binary&gt;'' are identical to those above.
 
As in the ''Record'', the ''Group'' may contain either ''Fields'', or ''Group_Fields'', or both intermixed.  ''Group_Fields'' may be nested arbitrarily deeply.  The requirement for these data structure classes inside a ''&lt;Group_Field_Binary&gt;'' are identical to those above.

Revision as of 14:19, 28 May 2013

The <Table_Binary> class contains the data structure definition for a binary table. Each row in the table has the same structure, defined in a Record_binary class. Records are themselves composed of scalar fields, or sub-records called "grouped fields". Use it if your data cannot be reasonably archived as fixed-width character tables because of data volume.

N.B. SBN Data Preparers: Our users and our reviewers have a very strong dislike for binary tables because of the difficult and subtle issues involved in using the data, and especially in using binary data from multiple sources. If you don't have at least three good archival reasons for using binary tables, don't do it. If you do anyway there is a very high probability that you will be directed to convert them to character tables by the peer review panel.
Also, if you supply data in a binary table format, you should also plan to supply a sample of a few records that have been translated to an ASCII format, for end-users to reference when they are trying to verify that they are reading the data correctly.
When in doubt, talk to your SBN data consultant.

For additional explanation, see the PDS4 Standards Reference, or contact your PDS node consultant.

Following are the attributes and subclasses you'll find in <Table_Binary>, in label order.

Note that in the PDS4 master schema, all classes have capitalized names; attributes never do.

<name>

OPTIONAL

If you'd like to give this table a descriptive name, here's the place to do it.

<local_identifier>

OPTIONAL

If you want to reference this Table_Binary from somewhere else in this label, give it a formal label here. Use an identifier that would make a valid variable name in a typical programming language, and you should be OK syntactically.

<offset>

REQUIRED

The offset, in bytes, from the beginning of the file holding the table data to the first byte in the table. You must specify the unit for this keyword, like this:

    <offset unit="byte">0</offset>

<records>

REQUIRED

This is the total number of records in the table. Records in binaries tables do not usually have record delimiters. On the rare occasions when they do, they are documented as a record field.

<description>

OPTIONAL

This attribute provides a place for additional free-format text comments.

<Uniformly_Sampled>

OPTIONAL

If this Table_Binary contains records which are uniformly spaced in some dimension (time, wavelength, distance, etc.), you can use this class to define that dimension and interval rather than including an additional field in each row to hold the value explicitly. The details are on the Filling Out the Uniformly Sampled Class page.

Here's a quick summary of what's in that class. All but sampling_parameter_scale are required:

  • sampling_parameter_name
  • sampling_parameter_interval
  • sampling_parameter_unit
  • first_sampling_parameter
  • last_sampling_parameter
  • sampling_parameter_scale

<Record_Binary>

REQUIRED

This class describes the structure of one complete record in the table.

<fields>

REQUIRED

The number of Field classes directly under (that is, in the first nesting level of) the Record class. Do not count Field classes nested under Group_Field classes.

If your Record contains only one or more Group_Field classes, this will have a value of zero.

<groups>

REQUIRED

The number of Group_Field classes directly under (that is, in the first nesting level of) the Record class. Do not count Group_Field classes under other Group_Field classes.

If your Record contains only one or more Field classes, this will have a value of zero.

<record_length>

REQUIRED

The total length of the record, including all fields, all repetitions of group fields, and any fill space between fields. You must specify a unit of bytes for this value:

    <record_length unit="byte">1234</record_length>

A Note about Fields and Group_Fields

Records are composed of Fields and Group Fields. A Record must have at least one of those (either will do), and can have an arbitrary number of them, in any order (that is, you can have Fields and Group Fields interspersed). Note, however, that Group Fields are never necessary - they are a notational convenience to save writing out large numbers of essentially identical Field definitions.

SBN data preparers should never use a Group_Field where a reasonable set of Fields will do. In particular, no Group_Field should have a <repetitions> count of less than 2 in any SBN data product. If you have data that seem like they should be an exception, please contact your SBN data consultant with the details.

<Field_Binary>

OPTIONAL

The class defines a single scalar field.

<name>

REQUIRED

The name of the field. SBN recommends that this be something fairly human-readable that can be easily turned into a variable name for use in applications, or displayed as a meaningful column heading.

<field_number>

OPTIONAL

This is the sequential number of the Field definition. For SBN data products, the field_number is intended to be a help to human readers trying to map field definitions to columns in a print-out of the Table.

SBN will generally require <field_number> be used in all flat tables (i.e., those without Group_Fields).
The Standards Reference lays out rules for using the field_number in cases where there are Group_Fields present which can be useful in programmatic contexts, but not so much in the visual-inspection case. For these tables SBN considers field_number and group_number to be optional.

<field_location>

REQUIRED

This is the location, in bytes, of the first byte in the field. (Note that locations begin with one, rather than zero.) You must indicate a unit of bytes for this field:

    <field_location unit="byte">1</offset>

<data_type>

REQUIRED

The type of the values in the field. This must be one of the values listed in the [Values Quick Reference] for binary table fields.

<field_length>

REQUIRED

The length of the field, in bytes. You must specify the unit:

    <field_length unit="byte">12</field_length>

<field_format>

OPTIONAL

The value of this attribute is a string representing the optimal print format for the data in the field, using a subset of the POSIX print conventions defined in the Standards Reference, and also described on the PDS4 field format Conventions page.

SBN will require that this attribute be present in all Field definitions. It is used for validation of the Table contents.

<unit>

OPTIONAL

If the value in this field has an associated unit, this is where it goes. This value is case sensitive, and you may use characters from the UTF-8 character set (like the Angstrom symbol) where appropriate.

Note: If a field contains a unitless value, then there should be no <unit> attribute. NEVER include a null unit value, or even worse, this: <unit>N/A</unit>.

<scaling_factor>

OPTIONAL

f the observational values of this field were scaled prior to writing, this attribute should contain the value the data must be multiplied by to get back to the original value. Scaling factors are applied prior to adding any offset.

<value_offset>

OPTIONAL

f the observational values of the field were shifted by an offset prior to writing, this attribute should contain the value that must be added to each field value to get back to the original value. Offsets and added after the scaling factor, if any, is applied.

<description>

OPTIONAL

Free-format text describing the content of the field.

Note: While not required, SBN expects to see a useful definition for every Field, as do both reviewers and users. Omit this field at your peril.

<Special_Constants>

OPTIONAL

This class defines flag values used to indicate that a particular field value is unknown for one reason or another. It is identical to the <Special_Constants> class used in the Array classes. For details, check the Filling Out the Array 2D Data Structure - <Special_Constants> page. Here is a quick list of the special constants available in this class:

  • saturated_constant
  • missing_constant
  • error_constant
  • invalid_constant
  • unknown_constant
  • not_applicable_constant
  • valid_maximum
  • high_instrument_saturation
  • high_representation_saturation
  • valid_minimum
  • low_instrument_saturation
  • low_representation_saturation

<Field_Statistics>

OPTIONAL

If you want to include things like extrema, mean value, and such for all the values that occur in this field through all the records in the table, this is the place to do it. This class is identical for all Field types. For details, see Filling Out the Field Statistics Class. Here is a quick list of the field statistics available in this class:

  • maximum
  • minimum
  • mean
  • standard_deviation
  • median

<Packed_Data_Fields>

OPTIONAL

When several values are packed into a single field, ignoring byte and word boundaries, the set of values is first defined as a single <Field_Binary>, which of course has an integral number of bytes. Then, the individual values that were packed into the string of bytes are defined as a series of <Field_Bit> classes inside this Packed_Data_Fields class.

SBN end-users and reviewers hate packed data even more than binary data, so the same caveats apply. If you absolutely have to use this class, see Filling Out the Packed_Data_Fields Sub-Structure.

<Group_Field_Binary>

OPTIONAL

This class defines a set of Fields and Group Fields that repeats a given number of times in each record. Group Fields may be nested.

Note: Unless you have three good reasons, don't use Group Fields in SBN data products.

<group_number>

OPTIONAL

Analogous to field_number for scalar fields, this is a sequential number useful for referencing Group_Field classes at a single nesting level of a complex Record definition.

<repetitions>

REQUIRED

The number of times the complete set of Fields and Group Fields comprising the <Group_Field_Binary> repeats.

Note: The minimum value for this field listed in the data dictionary is one, but no product will pass SBN review unless this value is at least two.

<fields>

REQUIRED

The count of Field classes directly under (i.e., at the first nesting level below) the Group_Field definition. This will be zero if the group contains no scalar Fields.

<groups>

REQUIRED

The count of Group_Field classes directly under (i.e., at the first nesting level below( the present Group_Field definition. This will be zero of the group contains no nested Group_Field classes.

<group_location>

REQUIRED

This is the location of the first byte of the first field of the first repetition of this group. You must specify a unit of "byte" for this value. If the group starts at the beginning of the containing Record or Group, this has a value of one. For example:

    <group_location unit="byte">1</group_location>

This value should be set bearing in mind that it will be used as the base offset for locating each repetition of the group. In other words, the location of the start of the first repetition of the group is group_location + 0*group_length; the location of the start of the second repetition of the group is group_location + 1*group_length, and so on.

<Fields> and Nested <Group_Fields>

As in the Record, the Group may contain either Fields, or Group_Fields, or both intermixed. Group_Fields may be nested arbitrarily deeply. The requirement for these data structure classes inside a <Group_Field_Binary> are identical to those above.