4  General Specification
This section contains general concepts and specifications that pertain to the transfer module
specifications of section 5.  It also specifies the general elements of an implementation and
the relationships of the logical constructs of the data models to the general elements of a
detailed implementation as well as general constraints on implementations.  This section
consists of two main parts:  (1) the underlying models and (2) specific transfer module
specification conventions used in section 5.  This section also contains specifications for the
relationships of the logical constructs of the model to the general constructs of an
implementation.
4.1  Spatial Data Transfer Models
Three data models-- the conceptual model, the data structure model, and the transfer
model-- form the basic foundation for the process of converting from a user representation
of a spatial entity to a corresponding digital object representation in a spatial data transfer.
4.1.1 The Conceptual Model of Spatial Data.  This model describes the spatial objects, as
well as the logical and topological relationships between the spatial objects and the captured
spatial entities.  This general model is object oriented and is also based on existing
topological and graph models for spatial data.  The conceptual model is presented in section
2 and more fully described in annex A.
4.1.2 The Data Structure Model.  This model is used to express the spatial objects of the
conceptual model in terms of transfer data structures.  The data structures used in this
transfer standard are based on the traditional relational and network models.  Data
structures viewed as spatial data structures are both the traditional vector and raster models.
One or more data structures used in the transfer are encoded in the Profile Specification
subfields of the Conformance field in the Identification module.
4.1.3 The Transfer Model.  This model is used to express the logical constructs of the
transfer form in terms of implementation-media constructs.  The implementation constructs
are made operational by an implementation method.  The implementation method selects
one or more media and defines the constructs pertaining to those media.
The transfer model is defined in terms of its constructs and logical relationships.  It deals
with three types of transfer constructs:  (1) logical constructs solely pertaining to this
standard, (2) constructs relating to the implementation method, and (3) constructs solely
pertaining to the transfer media.  The three types are summarized in tables 3a and 3b.
Logical characteristics of constructs are defined in 4.2 that have physical instances that are
implementation and (or) medium dependent.  Definitions for the corresponding physical
constructs may be found in the implementation requirements of part 3 where additional
constraints exist.
                                                 Table 3a Transfer constructs of this standard
           Construct                                              Logical               Implementation                  Media
           Spatial Data Transfer                                  X                     X                               X
           Module                                                 X
           Module record                                          X
           Module field                                           X
           Module subfield                                        X
           Subfield                                                                     X
           Field                                                                        X
           Record                                                                       X
           File                                                                         X                               X
           File set                                                                     X
           Volume                                                                                                       X
           Volume set                                                                                                   X
           Media record                                                                                                 X
Table 3b depicts the relationships of the logical constructs specified in part 1 of this
standard to the implementation constructs of part 3 and to typical media constructs.
           Table 3b Relationships between the transfer logical constructs,
                      implementation constructs, and typical medium constructs
           Logical Constructs                          Implementation                              Medium
           of this Standard                            Constructs                                  Constructs
           spatial data                     >          file set                         >          volume set
           transfer                                                                                ^
                                                                                                   ^
           ^                                           ^                                           volume
           ^                                           ^                                           ^
                                                                                                   ^
                                                                                                   p
           module                           p>>        file                             =          file
           ^                                           ^                                           ^
           ^                                           ^                                           ^
           module record                    p>>        record                           p>>        media record
           ^                                           ^
           ^                                           ^
           module field                     p>>        field
           ^                                           ^
           ^                                           ^
           module subfield                  =          subfield
           Note:      B          =          A          implies functional equivalence of A and B
                      B          >          A          implies A contains one of B
                      B          >>         A          implies A contains one or more of B
                      B          p>>        A          implies A contains part of, or one or more of B
The transfer model specifies relationships of the following basic types: (1) implicit
relationships between constructs expressed through order and (2) explicit cross-references
between constructs.
4.1.3.1 Ordering Concepts.  An implementation of this standard shall preserve the meaning
of the data including any logical associations required by this standard.  The specifications
require:
                     the preservation of or means for reconstruction of a logical order in which the
                      recipient may retrieve data comprising module subfields, module fields,
                      module records, and modules.
                     the preservation of the identity of the interchange data elements.
The general principles behind these requirements are explained as follows.
Order is the sequential arrangement of elements in a construct.  In a data transfer, the
reason for a sequential arrangement is that each element has an implied sequence number
that serves to identify its participation in the construct, so that its structure can be preserved.
This standard does not impose general ordering requirements for transfer constructs with
specific identification.  In particular, most modules, which are assigned unique module
names, and fields and subfields that carry names assigned by the standard, need not occur
in any specific order in the context in which they are used.  However, the order of
presentation in the standard is recommended as a default order.
The standard imposes ordering requirements on unnamed or nonuniquely named transfer
constructs such as elements in repetitive lists resulting from repeated fields and subfields.
This ordering can be imposed on repeated instances of fields or subfields to capture the
structure of the data to be transferred in such a repetitive list.  For example, repeated
instances of the Spatial Address field containing point data for a line shall be encoded in
a certain order and decoded in the same order to fully preserve the meaning of the line.
Ordering can also be imposed on repetitive instances of two or more types of fields when
elements of repetitive lists are correlated.  Ordering requirements of this type are imposed
on a field by field basis as set out in 4.1.3.3.3 and 4.2.3.3.
Wherever repetitive lists occur on which the standard does not impose any ordering
requirements, a user of the standard may still encode the field instances in a significant
order, and decode these instances in the same order, because any implementation shall
preserve the order for a repetitive list.  This is explicitly stated in 4.1.3.3.8, Preservation of
Order.
4.1.3.2 Backus-Naur Form.  For clarification, the Backus-Naur Form (BNF) is used to
concisely express structure, relationships, and layout of the transfer constructs in this
specification.
Each production rule has a left side (identifier) and a right side (expression) connected by
the symbol "::=", meaning that the left side is replaced by or produces the right side.  Terms
in the right side either match other identifiers or are terminal symbols.  Making substitutions
using matching symbols in the production rules therefore leads to explaining the highest
level identifier in terms of the lowest level terminal symbols.  Other identifiers are
intermediate, explaining the organization of the lower level symbols, and it is this expressive
power of BNF that is used to define the organization of the transfer constructs in this
standard.  Most often the terminal symbols will actually be absent, but the production rules
are presented in an indented form which indicates the levels of organization. The BNF used
here is an extension from normal usage, where the order of the terms in the right hand side
of the production rule implies a physical ordering of these terms (as characters in a
sentence, for example).  However, for data transfer, order may not be important at times,
and the terms may be considered a set.  When order is not important, the convention of
separating the terms with a "," will be used.
The symbols used in the production rules have the following meaning:
           Symbol                Meaning
           ::=                   is replaced by, produces, consists of
           |                     exclusive or
           []                    term enclosed is optional (not used or used once)
           {}                    term enclosed is used any number of times
                                            (not used, used once, or used several times)
           <>                    term enclosed is nonterminal
           ,                     exists together with (no order implied)
           ...                   indicates a repetitive list of similar items
4.1.3.3 Implicit Relationships between Constructs.  The ordering relationships between the
logical constructs of this standard in the transfer are designated in table 3b.  This table also
designates the relationships between the logical constructs and the implementation and
media constructs.
           4.1.3.3.1 Modules within a Spatial Data Transfer.  Spatial data transfers may occur
on sequential media where order is significant, or on random access media where,
depending on the level of detail, order might not be significant.  On a medium where order
is significant, the Identification Module and the Catalog modules shall be the first modules
in the sequence.  Unless otherwise specified by the Catalog/Directory module, the
remaining modules shall be organized in the order that they appear in section 5.  When the
Catalog/Directory module implies a different ordering, this default ordering for the
remaining modules is not required.  For random access media the Identification modules
and Catalog modules shall be easily identifiable, preferably through file names that reflect
the module type.  Regardless of the type of media used, each global information module
(see table 8 for a list of global module types) shall be contained in one or more separate
files that contain only that module.
Modules may be included or omitted, with the following exceptions:
           (a)        Modules referred to by foreign identifiers in other modules in the transfer
                      shall also be present in the transfer.
           (b)        The global modules stated as required in 5.2 shall always be present.
           (c)        The inclusion of the Identification module is mandatory.
           (d)        When the Attribute Authority or Entity Authority subfield of any Data
                      Dictionary/Schema module is null, or when the authority referred to is an
                      authority other than this standard, appropriate Data Dictionary modules to
                      define the entity or attributes and (or) the entity or attribute authority shall
                      be used.  Detailed conventions for the use of the authority subfields are found
                      in 5.2.6.
                      Data Dictionary/Definition and Data Dictionary/Domain modules may be
                      separate and external to a transfer, but if separate, they must be uniquely
                      referenced (by module name and version) and labeled as "external" in
                      Catalog/Directory records.  The separate Data Dictionary modules shall easily
                      merge with SDTS transfer data which reference them (e.g. no module name
                      conflicts, no file name conflicts, and only editing of the Volume and External
                      subfields of the Catalog/Directory module records for the Data
                      Dictionary/Definition and Data Dictionary/Domain modules).
           (e)        The five quality modules described in 5.3 shall always be included.
                      Data Quality modules may be separate and external to a transfer, but if
                      separate, they must be uniquely referenced (by module name and version) and
                      labeled as "external" in Catalog/Directory records.  In addition, external Data
                      Quality modules shall have no records with foreign identifier fields.  The
                      separate Data Quality modules shall easily merge with SDTS transfer data
                      sets which reference them (e.g. no module name conflicts, no file name
                      conflicts, and only editing of the Volume and External subfields of the
                      Catalog/Directory module records for the Data Quality modules).
           (f)        For each Attribute Primary or Secondary module there shall be a related
                      Schema module.
           (g)        For each Raster Cell module there shall be a related Raster Definition
                      module.  For each Raster Definition module there can be more than one
                      related Raster Cell module.
           (h)        For the Line Representation, Symbol Representation, and Area Fill
                      Representation modules, a standard field can take on specified values that are
                      defined in the domain description column, or additional values defined in a
                      Data Dictionary module.  If additional values are used, the values and the
                      authority for the values shall be defined in an associated Data Dictionary
                      module, and the Data Dictionary module shall always be present.
           4.1.3.3.2 Module Records within Modules.  Module records should preferably occur
in ascending sorted order, according to the module record identifier field.  Module records
representing spatial objects or relationships between components of spatial objects shall
occur in the order dictated by the spatial data model (2.1.2).
           4.1.3.3.3 Module Fields within Module Records.  It is recommended that module
fields within module records occur according to the sequence specified in section 5.  Module
fields may occur in a different order on a module by module basis, provided that each field
is identified through the selected implementation method and that significant relationships
between fields are preserved.  Within a module, the ordering, type and number of types of
fields shall be identical for each module record.  Multiple Object Representation codes are
allowed within the same module (see 5.6 and 5.7).
Module fields within each module description are arranged so that within a given module
record the primary module field will not repeat, whereas the instances of the secondary
module field may repeat a fixed or variable number of times.
The structure of a module with a primary field "Primfield" and secondary fields "Secfield1,
Secfield2,...,Secfieldn" is expressed as:
 <module record>::= <Primfield>, {<Secfield1>}, {<Secfield2>},
        ..., {<Secfieldn>}
The rules for the case where a field is absent are given in 4.1.3.3.5.
The order of repetition of a module field can be significant. Moreover, the order of
repetition can be correlated with the order of repetition of another field. The following
three classes are therefore recognized:
           (a)        The order of repetition is not significant.
           (b)        The order of repetition is significant.
           (c)        The order of repetition is significant and is correlated with the repetition of
                      another field.
This standard dictates for each field which of the above conditions apply through an
appropriate code in the field description for each field (see 4.2.3).  This indicates whether
ordered information shall be supplied for that field.
A number of modules in this specification have a simple relational structure in which all
subfields may be represented as an n-tuple within a single implementation field. A module
is said to have a relational structure when either one of the following conditions exists:
           (a)        there is only a single primary field per module record and no variably
                      repeating subfields.  The relational structure of a module record is:
                                 <module record>                  ::=         <Primfield>
                                    <Primfield>                   ::=         <Subfield1>,
                                                                              [<Subfield2>],
                                                                                     .
                                                                                     .
                                                                              [<Subfieldn>]
                      where the subfields are optional according to the rules of 4.1.3.3.6.
           (b)        the module record is composed of one primary field and one or more
                      nonrepeating secondary fields.  This alternate form is sometimes present to
                      take advantage of predefined shared fields.  This structure is expressed as:
                      <module record>::= <Primfield>, <Secfield1>, [<Secfield2>],
                            ..., [<Secfieldn>]
                      where the optionality of the fields is according to the specifications of
                      4.1.3.3.5.
           4.1.3.3.4 Subfields within Fields.  A module subfield with a given name may be
repeated a variable number of times within a given spatial data transfer if this is so specified
within this standard (see 4.2.3.5).
           4.1.3.3.5 Optionality of Module Fields.  Module fields may be included or excluded.
Both inclusion and exclusion may be either mandatory or optional, depending on the context
for the use of the fields.  When included, field contents may be null or may not be null.
The following rules apply.  Unless stated otherwise in a particular field description in the
module specification table, module fields may be omitted provided that fields can be
properly identified in the decoding process without additional external information not
contained in the transfer.  This can be satisfied with the current implementation method that
uses tagged fields.  The meaning of missing module fields is specified in 4.1.3.3.9. Mandatory
fields shall not be null.  The mandatory absence of fields shall have the meaning of
"undefined, not relevant," as specified in 4.1.3.3.9.  Mandatory fields in mandatory modules
shall never be absent or null.
           4.1.3.3.6 Optionality of Module Subfields.  Module subfields may be included or
excluded.  Both inclusion and exclusion may be either mandatory or optional, depending on
the context for the use of the subfields.  When included, subfield contents may be null or
may not be null.  The following rules apply.  Unless stated otherwise in a particular subfield
description in the module specification table, module subfields may be omitted provided that
subfields can be properly identified in the decoding process without additional external
information not contained in the transfer.  This can be satisfied with the current
implementation method that uses labeled subfields.  The meaning of missing module
subfields is specified in 4.1.3.3.9.  Mandatory subfields shall not be null.  The mandatory
absence of subfields shall have the meaning of "undefined, not relevant," as specified in
4.1.3.3.9. Mandatory subfields in mandatory modules shall never be absent or null.
           4.1.3.3.7 Extra module fields and subfields shall not be added, except under private
agreement.  The names and mnemonics used for any additional fields and subfields, under
such an agreement, shall not duplicate any of those specified in the standard.
           4.1.3.3.8 Preservation of Order.  For a repetitive list, the implementation shall
preserve the order as received from the sender, and on output, preserve order as found on
the media.
           4.1.3.3.9 Nulls and Defaults.  The definition and the method for implementing null
values is implementation dependent, and for the user-defined fields and subfields will be
application specific.  Null values in fields and subfields may be indicated in two ways:  (l)
through the structure imposed on a transfer's contents by the implementation, and (2)  by
setting aside certain values in the domain of the specified field or subfields contents as null
values.  Structure indicated null values may be manifest in two ways:  (l)  through the
absence of fields or subfields, and (2) through empty fields or subfields.
For the purposes of this standard, the default method for indicating null values shall be
through the structure imposed by the implementation.  Empty fields and subfields shall have
the meaning of "missing, relevant but not known," while missing fields and subfields shall
have the meaning of "undefined, not relevant."  If this default option for implementing null
values is not feasible, the user may define alternative meanings to missing and empty fields
or subfields, or may opt to implement a different null scheme by designating domain values
as null values.  In this case, the user shall fully describe the selected method in the data
quality Logical Consistency module, and if applicable, shall specify the designated null
domain values in a Data Dictionary/Domain module.
The fields and subfields that may be omitted, and when omitted have the meaning of
"undefined, not relevant," are specified in 4.1.3.3.5 and 4.1.3.3.6.
A subfield may have an associated default value that must be assumed in effect when the
subfield is omitted from the transfer.  In this specification, subfields with default values are
flagged appropriately and the default values are indicated.  Values of omitted subfields
without a preassigned default value are assumed to be of the null type "undefined, not
relevant," unless otherwise specified in the Logical Consistency module.
4.1.3.4 Explicit Relationships between Constructs.  The following relationships between
constructs are explicitly encoded in the spatial data transfer.  The relationships described
are not only restricted to relationships between transfer constructs, but also include other
elements of the transfer such as spatial addresses and attributes.
           4.1.3.4.1 Modules, Records, Files, and Volumes.  As indicated in table 3b, a module
record may occur in a part of, in all of, or in more than one media record, file, or volume.
Global modules may occur in all of or in more than one media file, but shall not share the
same media file with other modules.  The Catalog/Directory module may be used to specify
which records, files, and volumes are associated with a particular module.  Each
Catalog/Directory module record shall have a single field with subfields containing
identifiers for module, record, file, and volume. More than one catalog module record may
be used to express the relationships between a specific module and its associated media
records, files, and volumes.
           4.1.3.4.2 Module Cross-References.  Certain modules can reference, have bearing on,
or relate to other modules.  These relationships are specifically expressed in the
Catalog/Cross-Reference module.  Each module record in this module shall have one field
consisting of four subfields, containing module names and types for two modules.
           4.1.3.4.3 Modules and Spatial Domain.  Relationships between modules and spatial
domain, map, theme and aggregate object (e.g., graph) are expressed through the
Catalog/Spatial Domain module.
           4.1.3.4.4 Module Record Cross-References.  Explicit relationships between module
records are established through module record identifiers and foreign identifiers.
           Module Record Identifiers
                      A module record identifier shall provide a unique identification for the record
                      in the entire transfer.  The identifier has two subfields: (1) Module Name and
                      (2) Record ID.  The module record identifier exists as the first two subfields
                      of the primary module field associated with the module record.  The record
                      number shall be unique within the module.
           Foreign Identifiers
                      References to other records from a given record shall be made through
                      foreign identifiers.  Foreign identifiers consist of three subfields: (1) Module
                      Name, (2) Record ID, and (3) Usage Modifier (see 5.1.2).  Module Name and
                      Record ID are mandatory subfields corresponding to the mandatory module
                      record identifier fields with matching names.  The Usage Modifier subfield is
                      optional and has no equivalent module record identifier subfield.
           4.1.3.4.5 Wildcard Characters in References.  For the purpose of eliminating multiple
module reference records and multiple foreign identifiers for those cases where the
reference model is one-to-many, the use of wildcard characters is allowed where indicated
in a module domain description table in section 5.  Wildcard characters are also used in
attribute definition relationships.  Except for the Record Identifier subfield, the subfield
containing wildcard characters must be alphanumeric.  When so indicated, the following
rules apply:
           (a)        An entire data element may be replaced with a "*", meaning "all."
           (b)        If the data element refers to the Record ID subfield, it may be replaced by
                      a negative integer corresponding to the maximum value in the subfield
                      referenced, e.g., "-9328", meaning "all 9,328 records in the module referenced,"
                      or "the maximum number of records referenced in any of the referenced
                      modules is 9,328."
           (c)        Non-contiguous substrings of a data element may be replaced with a "*",
                      meaning that the data element refers to those other data elements where the
                      explicitly specified substrings are matched in their relative order.
           (d)        Single characters of a data element may be replaced with a "?" meaning that
                      the data element refers to those other data elements where the explicitly
                      specified characters match in their relative order.
Whenever wildcard characters are used in data items that are part of a nested index, such
as the foreign identifier, the scope of the elements referenced shall be restricted by the
scope of the previous level of reference.  For example, if wildcard characters are used in the
same foreign identifier to refer to modules and also to refer to records, then the scope of
the records is restricted to the set of modules referenced.  For any transfer, the scope of a
set of modules referenced shall be restricted to the modules in the Catalog/Directory
module in which the referring module is cataloged.
The use of wildcard characters in the Module Name subfield of a foreign identifier field is
not permitted except in global modules.
4.1.3.5 Spatial Registration.  The standard includes a number of mechanisms by which
spatial data contained in the transfer can be related to locations on the Earth's surface.  The
primary goal of this standard is to promote the transfer of data for which all spatial
addresses have a known (and expressed) relationship to latitude and longitude.  However,
for certain types of applications this might not always be possible or meaningful.  The
standard therefore recognizes three spatial registration conformance levels.  A transfer with
conformance levels 1 or 2 shall contain data that have a specified relationship to latitude
and longitude, while this relationship shall remain unspecified for a level 3 transfer.
The known relationship to latitude and longitude is expressed through the use of an external
coordinate reference system, of which the three most widely used in the United States are
(listed in order of preference): Latitude and Longitude (also termed Geographic), Universal
Transverse Mercator/Universal Polar Stereographic (UTM/UPS) Grid Systems, and State
Plane Coordinate Systems (metric).  These systems are mathematically interconvertible, on
a point by point basis, and are also officially recognized by many mapping and surveying
agencies of the Federal and State governments.  This standard allows the use of any of these
preferred systems as the external coordinate reference system for spatial registration
conformance level 1, and no other system shall be used for this conformance level.
Any other external reference system may be used for registration conformance level 2, in
which case the standard requires a full disclosure of the reference system, its projection and
parameters.  The spatial registration conformance levels are summarized as:
           Level 1               Relationship with latitude and longitude known through the use of one
                                 of the preferred external reference systems
           Level 2               Relationship with latitude and longitude known through the
                                 specification of an external reference system and its projection and
                                 parameters
           Level 3               Unspecified relationship with latitude and longitude
In addition to the latitude-longitude system and the specified external reference system, the
standard includes two additional reference systems: the internal reference system and the
scan reference system.  The four types of spatial referencing systems are defined as follows:
           (a) The scan reference system is a row-column reference system for use with raster
                      data, further described in 5.7.1.2.
           (b) The internal reference system is a Cartesian coordinate system, one that does not
                      assume any particular orientation.  For raster data, the system shall be right-
                      handed.  The internal reference system is used to store the spatial addresses
                      for the vector spatial objects of a transfer, while the scan reference system is
                      used to store spatial addresses for raster data.
           (c) The external reference system is also a Cartesian coordinate system, without an
                      assumed orientation, but the orientation of the internal and external reference
                      systems shall be identical.  The external reference system shall be either the
                      Latitude-Longitude system, the UTM/UPS System, one of the State Plane
                      Coordinate Systems (metric), or a system for which a transformation to
                      latitude and longitude can be described through a projection and its
                      parameters.  The external reference system is not used to transfer the spatial
                      addresses of spatial objects, but is used within a transfer to record registration
                      points and spatial domains.
           (d) The system of latitude and longitude is the ultimate reference system to which,
                      for conformance levels 1 and 2, all spatial data shall be convertible.
The standard provides the necessary information to transform spatial addresses from one
reference system to another for the following transformations:
           (a) Scan reference system to internal reference system.  This transformation is for
                      raster data, and is defined through the parameters stored in the Raster
                      Definition module (5.7.2).
           (b) Internal reference system to external reference system.  This transformation may
                      be accomplished (1) through translation and scaling with parameters provided
                      in the Internal Spatial Reference module, or (2) through a transformation
                      implicitly defined by registration points of the Registration module.
           (c) External reference system to latitude and longitude.  This transformation can be
                      accomplished through the known relationship between the preferred external
                      spatial reference systems to latitude and longitude, or through the explicitly
                      specified projection and parameters of another defined external reference
                      system.
This standard is implemented through the use of recognized horizontal and vertical datums.
The spatial address refers to the geographic point location of an object.  It is used to define
the position of a point (in a defined coordinate system) that can be on, above, or below the
Earth's surface.  A point location in any one of the described reference systems is specified
by means of a spatial address.  The scan reference system for raster data is a special case,
because it requires transformation from a row-column position to a spatial address in the
internal reference system.
The method of spatial addressing is specified in 4.1.3.5.1.  This is followed by the
requirements for constructing spatial addresses in any of the three preferred external
reference systems.  These requirements apply directly to the external spatial addresses of
the Registration and Spatial Domain modules only.  Otherwise, it is upon transformation
of internal reference system spatial addresses to external system addresses that the external
addresses shall meet the stated requirements.
Further information concerning the preferred external spatial reference systems is provided
in annex C.
           4.1.3.5.1 Spatial Address and Coordinate Coding.  This standard only allows for
spatial addressing techniques corresponding to the conventional method of Cartesian
coordinates.  Within this method, different numbers of subfields (depending on whether or
not a Z component is included) may be needed to form a complete spatial address.  The
specification for a spatial address is given in 5.1.1.  The type of address is identified in
5.2.4.1.  Specifications for altitude data are provided in 4.1.3.5.5.
Internal to the standard, the components of the spatial address are subfields with the labels
X, Y, and Z.  The Z component of the spatial address shall always correspond to the Z
component of the selected external reference system.  The X component of the spatial
address may be assigned to either one of the horizontal components of the selected external
spatial reference system, and similarly the Y component.  The selected assignment shall be
communicated through the Spatial Address Component Label subfields in the Internal
Spatial Reference Module.
           4.1.3.5.2 Latitude and Longitude.  Latitude and longitude are angular quantities and
shall be expressed as decimal fractions of degrees.  Whole degrees of latitude shall be
represented by a two-digit decimal number ranging from 0 through 90.  Whole degrees of
longitude shall be represented by a three-digit decimal number ranging from 0 through 180.
When a decimal fraction of a degree is specified, it shall be separated from the whole
number of degrees by a decimal point.
Latitudes north of the equator shall be specified by a plus sign (+), or by the absence of a
(-) sign, preceding the two digits designating degrees.  Latitudes south of the Equator shall
be designated by a minus sign (-) preceding the two digits designating degrees.  A point on
the Equator shall be assigned to the Northern Hemisphere.
Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the
absence of a (-) sign, preceding the three digits designating degrees of longitude.
Longitudes west of the meridian shall be designated by minus sign (-) preceding the three
digits designating degrees.  A point on the prime meridian shall be assigned to the Eastern
Hemisphere.  A point on the 180th meridian shall be assigned to the Western Hemisphere.
Any spatial address with a latitude of +90 (90) or -90 degrees will specify the position at
the North or South Pole, respectively.  The  component for longitude may have any legal
value.
           4.1.3.5.3 Universal Transverse Mercator/Universal Polar Stereographic Grid Systems.
           4.1.3.5.3.1 Universal Transverse Mercator Grid System.  The Universal Transverse
Mercator Grid System shall be used for spatial addresses between 84 degrees North and 80
degrees South Latitude.  The first graphics character of the Zone Number Subfield in the
External Spatial Reference module record shall be a code to indicate the hemisphere in
which the point is located.  A plus sign (+) shall be used to indicate the Northern
Hemisphere, and a minus sign (-) to indicate the Southern Hemisphere. The remainder of
the subfield shall contain the zone number indicating the 6 degree longitudinal band in
which the point is located (01, 02, ...60).  The unit of measurement for both Northing and
Easting shall be the meter.
           4.1.3.5.3.2 Universal Polar Stereographic Grid System.  The Universal Polar
Stereographic Grid System shall be used in place of the Universal Transverse Mercator Grid
System whenever the point is located north of 84 degrees North or south of 80 degrees
South Latitudes.  The Zone Number Subfield shall be filled according to the rules outlined
in paragraph 4.1.3.5.3.1, except the grid zone letter designator (A,B,Y, or Z) shall be used
in place of the 6 degree longitudinal band zone numbers.
           4.1.3.5.4 State Plane Coordinate Systems.  Currently, many of the SPCS's are, through
legislative mandate, referenced to the North American Datum Adjustment of 1983 and are
referred to as SPCS 83 systems.  The SPCS 83 systems are required to have their horizontal
components expressed in meters to conform to the SPCS specifications.  However, several
SPCS's remain that are referenced to the North American Datum of 1927 and are referred
to as SPCS 27 systems.  The SPCS 27 specifications required that the horizontal components
be expressed in feet.  The horizontal component of SPCS 27 data shall be converted to
meters.
An X or Y coordinate in an existing SPCS can be expressed by a number of the general
magnitude of NNNNNNN.NNN.  This will suffice for a range of not less than 0.003 meters
and not more than 3,000,000.000 meters and is considered to be appropriate for this
standard.  For the purposes of coordinate transfer, the following convention applies.  Where
a decimal fraction is used, it shall be one, two or three positions in length, as required (e.g.,
.1, .15, .125).
Each of the zones or SPCS's in each jurisdiction is uniquely identified by a four-character
numeric code as specified in table 4 of FIPSPUB 70-1.  This four character code shall be
transferred in the Zone Number subfield of the External Spatial Reference module.
           4.1.3.5.5 Altitude.  Altitude of a point, as used in this standard, is defined as the
distance in meters either above or below a reference surface.  The Vertical Datum and
Sounding Datum subfields of the External Spatial Reference module shall be used to specify
this surface.
All altitude measurements below the reference Vertical Datum shall be designated by a
minus sign (-) preceding the number.  Measurements at or above the reference datum, or
at or below the Sounding Datum, may be either without a sign or may be designated by a
plus sign (+), however usage shall be consistent throughout a set of data.
The unit of measurement shall be the meter.
4.1.3.6 Attributes
           4.1.3.6.1 Introduction.  Attributes shall be transferred as simple relational tables.
Each Attribute module record shall contain a table row.  Two types of attribute tables
exist:primary and secondary.  Each table row shall be stored as one module record of an
Attribute Primary or Attribute Secondary module.  The attributes shall be separate from the
spatial objects, but primary attributes shall be related to the objects through forward and
(or) backward foreign identifiers.  While the Attribute Primary module records are linked
directly to the spatial objects, the records for the secondary attribute tables are related to
primary attributes and (or) other secondary attributes through common attributes of the
same name and domain, allowing for a relational join between primary and secondary
tables.  Secondary attributes can provide additional information for the primary attributes
without having to repeat this information for each spatial object.  Secondary attributes can
also relate to other secondary attributes or to more than one set of primary attributes.  The
link between spatial object module records and Attribute Primary module records is a
one-to-one or one-to-many link.  For each spatial object there may be more than one
Attribute Primary module record, but more than one spatial object may not refer to the
same Attribute Primary module record.  The link between Attribute Primary and Attribute
Secondary module records may be one-to-one, one-to-many, or many-to-one.  Attribute
Secondary modules are linked to Attribute Primary modules or other Attribute Secondary
modules through possible relational joins on corresponding attributes.  The names and types
of related modules that can be joined shall be transferred in the form of module
cross-references expressed in the Catalog/Cross-Reference module.  The structure of an
Attribute Primary module record is defined as:
         <Attribute Primary module record> ::=                             <module record identifier>
                                                                               [<spatial object ID>]
                                                                               [<attribute 1>]
                                                                               [<attribute 2>]
                                                                                        .
                                                                                        .
                                                                                        .
                                                                               [<attribute n>]
             <module record identifier> ::=                            <module name>
                                                                         <record id>
                 <spatial object ID> ::=                       <module name>
                                                                 <record id>
where n is a constant for the module.
           4.1.3.6.2 Attributes and Schema.  The attribute subfields of both the Attribute
Primary and Attribute Secondary modules are generic subfields, to be defined by the user
of the standard.  Therefore, the information about the attributes is also user defined and
must be transferred as well.  The Data Dictionary/Definition module carries the definition
of attributes and entities. The Data Dictionary/Domain module specifies the attribute
domains. Specifications contained in these modules can be applicable to all attribute
modules in a transfer. The Data Dictionary/Schema module applies to specific tables, and
specifies the composition of these tables with respect to specific attributes used from among
the total set defined in the other Data Dictionary modules.  The Data Dictionary/Schema
module transfers five important types of attribute information:
           (a) The specific set of attributes in an attribute module
           (b) The relationship between these attributes and an entity
           (c) The authorities of the attributes and (or) entity
           (d) The format, measurement unit, and maximum length of an attribute
           (e) Whether an attribute is a part of a primary or foreign relational key.
The following subsections describe the first three types of attribute information.
           4.1.3.6.3 Attributes and Entity.  Part 2, section 2 defines an attribute as "a defined
characteristic of an entity type."  Attributes may also be used without reference to an
associated entity.  The combination of an attribute label and its associated authority is
considered unique.  Therefore, two attributes with the same label and authority shall have
the same definition and value domain throughout the transfer.
           4.1.3.6.4 Object and Entity.  As described, spatial objects are normally associated with
entities through attributes stored in Attribute Primary and Attribute Secondary modules,
that have associated Schema modules, in which the entity type may be stored.
           4.1.3.6.5 Attributes and the Universe and Void Polygons.  As stated in the definitions
of the universe and void polygons (2.3.3.3.1 and 2.3.3.3.2), the attribution of these objects
can be substantially different from the attribution of the other polygons of a two-dimensional
manifold.  This difference in attribution may be implemented in any of the following three
ways:
           (a) Polygons that are not universe or void polygons can have associated attributes
           referenced through the Attribute ID field of the Polygon module, while the universe
           or void polygons can lack any attributes, as indicated by the absence of the Attribute
           ID field.
           (b) A different schema applies to the universe and (or) void polygons.  In this case,
           the universe and void polygons shall be stored in a separate module.  This module
           shall be uniquely referenced to a special Data Dictionary/Schema module using a
           Catalog/Cross-Reference module.
           (c) The same schema applies to all the polygons of a module, including the universe
           and (or) void polygons.  The difference in attribution is accomplished through the
           proper application of nulls, as described in 4.1.3.3.9, to the attribute fields that are
           irrelevant for the universe and void polygons.
           4.1.3.6.6 Attribute Definition, Authority, and Domain.  Attribute meaning can only
be transferred through the association of an attribute label with an attribute definition.  The
Data Dictionary/Definition module is used to relate an attribute label to an attribute
definition.  It also relates the attribute label to the attribute source and attribute authority.
The attribute authority is the organization and (or) document through which a meaning is
assigned to the attribute label as it occurs in the transfer.  The attribute authority is not
responsible for the actual value assigned to the attribute in the transfer, other than the
specification of the value domain.  The description of the authority responsible for actual
value assignment shall be transferred through the data quality Lineage module (see 5.3.1).
Attribute and entity authorities shall be specified in the Attribute and Entity Authority
subfields of the Data Dictionary/Schema module.  If the authority subfields are null or
contain authorities other than this standard, then the attribute and (or) entity shall be fully
described through Data Dictionary module entries.  Detailed conventions for the use of the
authority subfields are found in 5.2.6.
A valid domain for each attribute can be specified through the use of the Data
Dictionary/Domain module.
           4.1.3.6.7 Foreign Identifiers as Attributes.  A foreign identifier shall be composed of
either two or three subfields: Module Name, Record ID, and an optional Usage Modifier
(see 5.1.2).  To facilitate joining attribute relations using foreign identifiers, and to facilitate
the implementation of relationships, the following special convention allows the storage of
foreign identifiers as single attribute values in a single subfield.  The format of the attribute
containing the foreign identifier shall be specified as "^" in the Format subfield of the
applicable Data Dictionary/Schema module (see 5.2.6.3), indicating that the attribute is a
"packed" foreign identifier.  The corresponding attribute subfield shall contain the
concatenated subfields of a foreign identifier as follows: Module Name and Record ID
separated by the Graphic Character "#" (for example, SOILCHAINS#34).  The optional
Usage Modifier shall follow the Record ID directly (for example, SOILCHAINS#34L).
When packed foreign identifiers are used, module names referred shall not contain the
graphics character "#".  The following BNF fully specifies the syntax of a packed foreign
identifier:
                      <packed foreign identifier> ::=                        <Module Name> '#'
                                                                             <Record ID>
                                                                             [<Usage Modifier>]
           4.1.3.6.8 Attribute Labels.  Attributes labels shall conform to the "identifier"
specification of the ANSI standard for the data base language SQL (ANSI X3.135-1986,
FIPSPUB 127).  This standard specifies an identifier as beginning with an uppercase letter
(SDTS alphabetic character A-Z) and followed by zero or more "character pairs."  A
"character pair" consists of an optional underscore (SDTS graphic character "_") and an
uppercase letter or digit (SDTS numeric 0-9).  Conforming to the SQL standard, the length
of an attribute label shall not exceed 18 characters.  An attribute label shall not be identical
to an SQL keyword. The BNF for the attribute label is:
           <attribute label> ::=                       <uppercase alphabetic character>
                                                       { <character pair> }
                      <uppercase alphabetic character> ::=                              A|B|C|D|E|F|
                                                                                        G|H|I|J|K|L|
                                                                                        M|N|O|P|Q|R|
                                                                                        S|T|U|V|W|X|
                                                                                        Y|Z
                      <character pair> ::=                        [ <underscore> ]
                                                                  <letter or digit>
                                 <underscore> ::=                            _
                                 <letter or digit> ::=                       <uppercase alphabetic character> |
                                                                             <digit>
                                            <digit> ::=           0|1|2|3|4|5|6|7|8|9
4.2  Transfer Module Specification Conventions
The following contains the conventions and notation for the module specification tables of
section 5.
4.2.1 Specification Layout
Each specification consists of a table describing the composition of records in a module.
A module record is composed of module fields consisting of a set of subfields.  Each
subfield has a specified data type and domain.  The columns of the specification table are
(1) Field Name, (2) Subfield Name, (3) Field/Subfield Description, and, for subfields, (4)
Data Type, (5) Domain, and (6) Domain Description.  Column (7) gives a four-character
mnemonic tag for each field and subfield specified.
The primary module field name for a module record shall be also the module type.  Subfield
names shall identify the data content of the module records.  The Data Type shall  indicate
the manner in which the field or subfield will be encoded.  Each of the codes shall have the
following meaning:
           A:         graphic characters, alphanumeric characters, or alphabetic characters
           I:         implicit-point (integer)
           R:         explicit-point unscaled (fixed point real)
           S:         explicit-point scaled (floating point real)
           B:         bitfield data (see types listed below)
           C:         character mode bitfield (binary in zero and one characters)
In some instances, one may select from two of the above types, in which case the code
letters will be separated by a vertical bar ( | ).  The data type used should always be
predictable.
The code "B" for bitfield data may have an additional qualification as follows:
           BI8:                  8-bit signed integer
           BI16:                 16-bit signed integer
           BI24:                 24-bit signed integer
           BI32:                 32-bit signed integer
           BUI:                  unsigned integer, length specified by implementation
           BUI8:                 8-bit unsigned integer
           BUI16:                16-bit unsigned integer
           BUI24:                24-bit unsigned integer
           BUI32:                32-bit unsigned integer
           BFP32:                32-bit floating point real
           BFP64:                64-bit floating point real
B or BUI binary patterns may be used when their extent can be described by the
implementation and the bit order is preserved by the implementation.  When B is used
without qualification, the bit pattern shall be interpreted according to a subfield description
contained in the Domain Value Definition subfield of the appropriate Data
Dictionary/Domain module.  When BUI is used, the bit string shall be interpreted as an
unsigned integer with the most significant bit first and least significant bit last.
The domain column specifies the set of values that may be encoded within the indicated
data type.  There are nine major domain specifications:
           (a)        Graphics characters (Gr-chars)
           (b)        Alphanumeric (Alphanum)
           (c)        Alphabetic (Alpha)
           (d)        Integer
           (e)        Real
           (f)        Binary
           (g)        Allowable values (domain enumeration)
           (h)        Standard code sets
           (i)        Standard field where domain is defined in Data Dictionary/Domain
                      module
In the first six cases (a, b, c, d, e, f), the domain column shall indicate "Alphanumeric,"
"Integer," etc.
In  case (g), the permitted values shall be listed, and each value shall be defined in the
domain description column.  The domain description column may provide further
restrictions on the allowable domain.  For example, if an alphanumeric item shall begin with
an alphabetic character, this will be stated.  When the domain column indicates "Integer,"
a positive, negative, or unsigned whole number is indicated.  A "Real" number on the other
hand calls for a positive or negative number with a fraction.  In either case, there shall be
no difference in meaning between a negative or positive zero.  The actual implementation
of an integer or real number shall be according to the domain Data Type in the Domain
Description Table and as further specified in ISO 6093 for numeric values in character string
format and ANSI X3.122-l986 (FIPSPUB 128) for binary data.  For additional information
see part 3.
In case (h), in most instances the number of a specific FIPS standard code set will be given,
preceded by the characters "cs:" (e.g., cs:FIPSPUB4-1 for calendar dates).  The Data
Dictionary modules also provide a general capability to use code sets from any other FIPS
standard as Attribute Values.  (See 5.2.6.)
In case (i), a standard field may take on specified values that are defined in the domain
description column and (or) additional values defined in a Data Dictionary/Domain module.
The notation in the domain column shall be preceded by "dd:" followed by any appropriate
limitation in the domain.  For example, dd:<0 means that negative values are permitted but
they must be defined in an associated Data Dictionary/Domain module.
Table 4 contains a complete enumeration of the character sets to be used for the graphics
characters, alphabetic, numeric, and alphanumeric domains.  All graphics characters shall
be encoded as specified in ANSI X3.4, extended to an 8-bit environment if required.  Note
that the set of graphics characters has been expanded slightly to include unprintable
characters for carriage return (CR), line feed (LF), backspace (BS), tab, and form feed (FF)
commonly found in text strings.
           Table 4 Character sets used to express the Graphics Characters,
                      Alphanumeric, Alphabetic, and Numeric domains1
                               Graphics Characters
                    Alphanumeric
           Alphabetic                                         Numeric
           A      N       a      n       SPACE              0      E2                   !       |      _
           B      O       b      o                          1      .                    "       /      {
           C      P       c      p                          2      +                    #       :      }
           D      Q       d      q                          3      -                    $       ;      FF
           E      R       e      r                          4      SPACE3               %       <      LF
           F      S       f      s                          5                           &       =      CR
           G      T       g      t                          6                           '       >      BS
           H      U       h      u                          7                           (       ?      TAB
           I      V       i      v                          8                           )       @
           J      W       j      w                          9                           *       [
           K      X       k      x                                                      ~       ]
           L      Y       l      y                                                      ,       \
           M      Z       m      z                                                              ^
           1The width of the line below the character set name indicates which characters are included in the set.
           2The "E" in the Numeric set is used for expressing an exponent.  Note that the characters ".","+", and
           "-" are not part of the Alphanumeric set.
           3SPACEs may be used in numeric forms as defined in ISO 6093.
4.2.2 Generic Versus Explicit Specification
Various specification elements, such as module names, field names, and subfield names, can
be specified generically rather than explicitly.  In this case, the user shall replace the generic
names with names composed by the user or selected by the user from a name substitution
table as indicated by the notation and naming conventions in the following.
An explicit specification is one that shall appear verbatim as documented in this standard
(independent of case).  Names may be abbreviated internal to the transfer as long as the
meaning of the data are unambiguously transmitted to the user of the standard (also see
4.1.3.1 and part 3, annex B).
4.2.3 Notation and Naming Conventions
This subsection specifies notation conventions for the nature and character of field names
and subfield names occurring in the module specification tables.
4.2.3.1 Explicit Specification.  All explicit field names are specified in alphabetic characters,
with the first character in uppercase.  Subfield names are specified the same as field names.
Upper and lowercase expression is only significant for the specification of this standard, not
for the content of field and subfield names in a transfer.
4.2.3.2 Generic Specification.  Generic field names and subfield names are specified in
lower-case alphabetic characters only, and the entire name shall be replaced by the user,
according to the instructions for the particular specification.
After user substitution, all specifications shall appear as though they were explicit
specifications.
4.2.3.3 Classes of Fields.  Fields may be grouped into different classes.  Some fields may
have repeated instances in the transfer, while others are not allowed to repeat.  For some
fields ordering may be important, while for others it is not.  Therefore, to designate the class
of a field, each field has one or more characters following its name.  The meaning of these
designations is as follows.
Primary fields are marked by (P), secondary fields where order of repetition is not
significant are marked by (R), and secondary fields where the order is significant are
marked by (O).  Secondary fields that shall not be repeated within a module record are
marked by (N).
Secondary fields where order of repetition is significant and is correlated with the repetition
of one or more other fields are designated as follows.  Each set of fields with a module
record where ordering is correlated will be assigned a character.  This character is appended
to the order symbol (O) for a field, symbolically expressed as (O/x), where x is replaced by
an uppercase alphabetic character in the specifications.  For example, if two fields named
Internal address and External address have an ordering relationship in which there is a
one-to-one correspondence between the elements in the list of instances of these fields, then
the pair of these fields is designated as set A and the fields are marked:
          Internal address (O/A)
          External address (O/A)
4.2.3.4 Repeated Subfields in Generic Specifications.  Certain subfields of a field, such as
the components of a spatial address, are generically identical and are thus described only
once in each generic specification.  In the generic specification, the number of these
subfields is variable because the number of subfields required depends on the individual
application.  After user substitution, however, the subfield names will be different, and the
number of subfields will be the same for the field throughout the entire module.  Subfields
of this type are specified only once and are flagged by a "+" in subsequent specifications.
For example, the subfield names for the attributes of an attribute module are  not known
until the user determines the types of attributes to be used in the  transfer. For this reason,
the generic specification for the subfield names of the Attributes field in the Attribute
Primary module (and similarly for the Attribute Secondary module) is as follows:
           FIELD                 SUBFIELD              FIELD/SUBFIELD
           NAME                  NAME                  DESCRIPTION
           Attributes (N)
                             (+) attribute
                                                       Primary attributes for the spatial object
with the meaning that the user should make substitutions for the "(+) attribute" generic
subfield name for his/her specific application so that for the user's purpose the table then
reads (for example):
           FIELD                 SUBFIELD              FIELD/SUBFIELD
           NAME                  NAME                  DESCRIPTION
           Attributes
                                 DEPTH                 Depth of soil
                                 TEXTURE               Texture of soil
                                 SLOPE                 Slope of soil
4.2.3.5 Variably Repeating Subfields.  Subfields with a given name and type that may repeat
a variable number of times (0 or more repetitions) within a given transfer will have a name
flagged by a "#" in subsequent specifications.
4.2.3.6 Shared Module Field Types.  Some module fields that occur in a number of modules,
and do not change from module to module, are specified only once in 5.1.  These fields will
thereafter be shown only as a field name; subfield names and descriptions will be omitted
from the module specification tables.  The entire field will be absent in the domain
description table.
For foreign identifiers and spatial addresses the shared  field is generic, and these fields may
then be assigned a different name in the module descriptions tables.  However, to indicate
that the contents and structure of these fields are either that of a foreign identifier or a
spatial address, foreign identifier fields will be prefixed with the symbol "^" and spatial
addresses will be prefixed with the symbol "-".
4.2.3.7 Subfields with Default Values.  Subfields that have a specified default value when
they are omitted from the transfer will be prefixed with the symbol "d".  The default values
are specified in the standard.
4.2.3.8 Mandatory and Optional Presence and Absence of Fields.  Presence or absence of
fields and subfields can be mandatory or optional, depending on the context in which the
field or subfield is used.  Unless the field is completely optional, one or more status codes
may appear in the field or subfield description in the Module Composition Table indicating
the disposition of the field.  The status code is enclosed in square brackets and consists of
up to three parts.  The first part is a key that can be followed by one or more conditions in
the second and (or) third part.  The key is one of four symbols with the following meaning:
           Key        No condition or true                        Condition false
           A          Mandatory absence                           Mandatory presence
           M          Mandatory presence                          Optional presence
           X          Mandatory absence                           Optional presence
           O          Optional presence                           Mandatory presence
The second part is an optional set of one or more Object Representation codes, separated
by vertical bars ( | ).  The third part is an optional set of field or subfield names with
optional values, separated by a "+" or "|", the plus indicating that both fields are present
and the vertical bar indicating that either one, but not both, fields are present.
For example, the Row Index in the Cell module is optional for raster objects with an Object
Representation Code "GK" when the Tesseral Index subfield is used.  This is indicated as:
Row Index [O/GK/Tesseral Index].  The Domain subfield in the Catalog/Spatial-Domain
module is optional if the Map, Theme, Aggregate Object subfield is used: Domain
[O/Map|Theme|Aggregate Object].
The required presence or absence of a field or subfield can also depend on the value of
another field or subfield.  This will be indicated by the field or subfield name, followed by
a "=" and by one or more values separated by vertical bars.  For instance, the Vertical
Component Format subfield is required when the value of the Spatial Address Type is
"3-TUPLE." This is indicated as: Vertical Component Format [M/Spatial Address Type =
3-TUPLE].
The following BNF fully describes the structure of the field and subfield status notation:
           status code ::=                  '['        <status key>
                                            ['/' <object representation codes> ]
                                            ['/' <field and subfield names > ] ']'
                <object representation codes> ::=                            <object representation code>
                                                                             {'|' < object representation code> }
                <field and subfield names> ::=                               <field or subfield>
                                                                             { <separator> <field or subfield>}
                      <field or subfield> ::=                                <field or subfield name>
                                                                             [ ' = ' value ]
                      <separator> ::=                                        '|' | '+'
                                 <field or subfield name> ::=                           <character string> |
                                                                                        <'character string'>
Each field or subfield can have one or more status codes, indicating the conditions under
which the field or subfield should be included, excluded, or optionally included.  A field or
subfield can have a single status code with an attached condition.  If the condition is false,
then the disposition of the field or subfield depends on the status code as indicated in the
table above.  For multiple status codes, the disposition of the field is determined by the
intersection of the logical conditions resulting from each status code.
The status codes are relative to the optionality of the module so that when a field or
subfield is mandatory, it is mandatory within each SDTS transfer only if the module in which
the field or subfield occurs is mandatory.
4.2.3.9 Notation Summary.  The notation conventions are as follows:
           Type of Name                     Generic Specification                       Explicit Specification
           Field name                       Lowercase                                   Initial uppercase
           Subfield name                    Lowercase                                   Initial uppercase
                                 Table 5 Summary of the special flags used with field names and subfield names
Flag
Used with
Meaning
(+)generic subfield
nameUser must substitute one or more
explicit subfields with user-assigned
names for the generic subfield in
the generic specification.
(#)subfield nameSubfield with given name and type
can be repeated an indefinite
number of times.
(P)field namePrimary module field.
(O)field nameSecondary module field where
order of repetition is significant
and the criteria for order are
specified.
(O/x)field nameSecondary module field where
order of repetition is significant,
and where the order is correlated
with the order of one or more
other fields belonging to the set x
(x to be replaced with an
uppercase alphabetic character).
(R)field nameSecondary module field where
order of repetition is not
significant.
(N)field nameNonrepeating secondary module
field.
(-)field nameContents and structure of the field
is that of a spatial address.
(^)field nameContents and structure of the field
is that of a foreign identifier.
(d)subfieldSubfield has a preassigned default
value when omitted from the
transfer.
           [A/..]                           field, subfield name                        Mandatory absence if condition
                                                                                        true; otherwise mandatory
                                                                                        presence.
[M/..]field, subfield nameMandatory presence if condition
true; otherwise optional.
[X/..]field, subfield nameMandatory absence if condition
true; otherwise optional.
[O/..]field, subfield nameOptional presence if condition true;
otherwise mandatory.
