-------------------------------------------------------------------------------

Constraint Name: Axis Type Restrictions

Definition:
 The following restrictions apply.

 1. In an <Enumeration Axis> instance X,

    1.1 The axis_type of X shall correspond to an EDCS Attribute T
        bound to the abstract value type EDCS_AVT_ENUMERATION.

    1.2 The entries of X's axis_value_array shall be distinct,
        valid EEs for T.

 2. In an <Interval Axis> instance X,

    2.1 The axis_type shall correspond to an EDCS Attribute (EA)
        bound to a numeric value type.

    2.2 If the axis_type is bound to some set of
        EDCS Unit Equivalence classes (EQs), the value_unit
        shall be a member of one of the specified EQs.

    2.3 Each individual entry in X's axis_interval_value_array
        shall have a value_type corresponding to an interval type,
        and this value_type shall be the same for all entries in
        the axis_interval_value_array.

    2.4 All entries in X's axis_interval_value_array shall
        be mutually disjoint.

    2.5 The entries in X's axis_interval_value_array shall be
        arranged in either monotonically ascending or
        monotonically descending order.

 3. In an <Irregular Axis> instance X,

    3.1 The axis_type shall correspond to an EDCS Attribute (EA)
        bound to a numeric value type.

    3.2 If the axis_type is bound to some set of
        EDCS Unit Equivalence classes (EQs), the value_unit
        shall be a member of one of the specified EQs.

    3.3 If the axis_type is not bound to any EQ, the
        value_unit and value_scale shall be set to EUC_UNITLESS
        and ESC_UNI, respectively.

    3.4 Each individual entry in X's axis_value_array shall
        have a attribute_value_type consistent with the axis_type,
        and this attribute_value_type shall be the same for all
        entries in the axis_value_array.

    3.5 All entries in X's axis_value_array shall be distinct.

    3.6 The entries in X's axis_value_array shall be arranged
        in either monotonically ascending or monotonically
        descending order.

 4. In a <Regular Axis> instance X,

    4.1 The axis_type shall correspond to an EDCS Attribute (EA)
        bound to a numeric value type.

    4.2 If the axis_type is bound to some set of
        EDCS Unit Equivalence classes (EQs), the value_unit
        shall be a member of one of the specified EQs.

    4.3 If the axis_type is not bound to any EQ, the
        value_unit and value_scale shall be set to EUC_UNITLESS
        and ESC_UNI, respectively.

    4.4 The value_type of the first_value and spacing field values
        shall be the same, and shall be consistent with the numeric
        data type to which the axis_type's value is bound.

 5. In regard to spatial <Axis> instances,

    5.1 A spatial <Axis> is an <Axis> instance with one of the
        following as its axis_type.

        5.1.1 For angular coordinates, such as latitude and
              longitude,
              EAC_SPATIAL_ANGULAR_PRIMARY_COORDINATE
              EAC_SPATIAL_ANGULAR_SECONDARY_COORDINATE.

        5.1.2 For x, y coordinates,
              EAC_SPATIAL_LINEAR_PRIMARY_COORDINATE
              EAC_SPATIAL_LINEAR_SECONDARY_COORDINATE

        5.1.3 For z and elevation coordinates,
              EAC_SPATIAL_LINEAR_TERTIARY_COORDINATE

    5.2 The first spatial_axes_count <Axis> components of a
        <Property Grid> instance shall be spatial <Axis> instances,
        each of which uniquely corresponds to a coordinate of
        the <Property Grid> instance's spatial reference frame.

    5.3 No other <Axis> instances in any other context shall be
        spatial.

Rationale:
 1. <Regular Axis>, <Irregular Axis>, and <Interval Axis>
    exist to specify some set of numeric values of an
    independent variable used to organize dependent values
    in some <Data Table> instance.

    Further, arithmetic operations are required to compute
    <Regular Axis>' tic values from its first_value and
    spacing field values.

 2. All <Axis> instances are required to specify distinct
    tic marks to avoid ambiguity.

 3. For ease of processing, it is desirable to organize
    <Interval Axis> and <Irregular Axis> values monotonically.

Example:
 1. axis_type = EAC_PRIMARY_SURFACE_THERMAL_CONDITION may be used
    only for an <Enumeration Axis> instance, and for no instance of
    any other <Axis> sub-class.

FAQs:
 Q. Can an EA of abstract value type INDEX be used
    for a <Regular Axis> or <Irregular Axis>?
 A. Yes, but the value_unit and value_scale fields
    are ignored, and interpolation_type is not applicable
    (and shall therefore be set to
    SE_INTERPOLATION_TYP_DISALLOWED).

 Q. For <Interval Axis> and <Irregular Axis>, why not require
    ascending monotonicity, rather than allowing either
    ascending or descending?
 A. In some problem domains, descending monotonicity is
    preferred, while in others, ascending is preferred.

    Consider a <Data Table> describing atmospheric data, where
    an <Irregular Axis> specifies a vertical coordinate in
    pressure units, which decreases with increasing height.
    In such a table, if the <Irregular Axis> were required to
    be monotonically increasing, it could not be used to define
    a volume without "flipping the atmosphere over" to put the
    highest level at the first point on the axis and the
    lowest level at the last point on the axis, which could
    lead to confusion when the <Data Table> is processed by a
    consumer.

    On the other hand, a <Data Table> describing oceanographic
    data with depth as an <Irregular Axis> might be naturally
    organized in terms of increasing depth.

-------------------------------------------------------------------------------

Constraint Name: Classification Data Constraint

Definition:
 1. For a <Union Of Features> instance UF,
    1.1 If UF has a directly attached <Classification Data>
        component, UF's union_reason may not be
        SE_UNION_REASON_OTHER.

    1.2 If UF has an inherited <Classification Data>
        component, UF's union_reason may not be
        SE_UNION_REASON_OTHER.

    1.3 Otherwise, UF's union_reason is required to be
        SE_UNION_REASON_OTHER.

 2. For a <Union Of Geometry> instance UG,
    2.1 If UG has a directly attached <Classification Data>
        component, UG's union_reason may not be
        SE_UNION_REASON_OTHER.

    2.2 If UG has an inherited <Classification Data>
        component, UG's union_reason may not be
        SE_UNION_REASON_OTHER.

    2.3 Otherwise, UG's union_reason is required to be
        SE_UNION_REASON_OTHER.

Rationale:
  The only permitted cases are those where a <Classification Data>
  is present to indicate either the SE_UNION_REASON_CLASSIFIED_OBJECT
  or SE_UNION_REASON_COLLECTION_OF_CLASSIFIED_OBJECTS cases, or where
  no <Classification Data> is present and the union is there for
  some non-semantic/non-environmental-object related reason.

Example:
 1. Consider a <Union Of Features> instance UF that is a
    component of a <Classification Related Features>
    instance. UF's union_reason cannot be
    SE_UNION_REASON_OTHER, because UF inherits the link
    object <Classification Data> of its branch.

 2. Consider a <Union Of Geometry Hierarchy> instance UGH
    with union_reason =
    SE_UNION_REASON_COLLECTION_OF_CLASSIFIED_OBJECTS,
    with a component <Union Of Primitive Geometry> instance
    UPG. UPG's union_reason cannot be SE_UNION_REASON_OTHER,
    because UPG inherits UGH's <Classification Data>.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Colour Mapping Restrictions

Definition:
 1. The colour_mapping field of a <Colour> shall not be empty.

 2. The Lgt_Render_Bhvr_Primary and
    Lgt_Render_Bhvr_Secondary flags may only be used for
    objects with <Light Rendering Properties>.

 3. The Lgt_Render_Bhvr_Primary flag may not be combined
    with any other SE_Colour_Mapping.

 4. The Lgt_Render_Bhvr_Secondary flag may not be
    combined with any other SE_Colour_Mapping.

Rationale:
 A <Colour> specifies how it is applied to the objects that use it, so
 the colour_mapping shall not be empty.

 The Lgt_Render_Bhvr_Primary and
 Lgt_Render_Bhvr_Secondary flags specify the primary and
 secondary colours of an object's <Light Rendering Behaviour>.

 If a <Colour> applies to the <Light Rendering Behaviour> of an object's
 <Light Rendering Properties> rather than the object itself, it shall
 apply only to that <Light Rendering Behaviour>. In addition, the same
 <Colour> cannot be both the primary and the secondary colour of a
 <Light Rendering Behaviour>.

Example:
 1. Consider a <Polygon> instance with 2 <Inline Colour> components and
    an <Image Mapping Function> component, where the
    <Image Mapping Function> instance's image_mapping_method is set to
    SE_IMG_MAPNG_METH_BLEND.

    Each <Inline Colour> instance shall specify whether it is primary,
    image blend, or neither, and which side of the <Polygon> instance is
    affected, in order to determine how to combine the colours with the
    texture.

FAQs:
 See the comments for <Colour>, SE_Colour_Mapping, and <Image Mapping
 Function> for discussions of how colour_mapping is interpreted.

-------------------------------------------------------------------------------

Constraint Name: Colour Table Size

Definition:
 For a given <Colour Table Group> instance G with table_size = k,
 each <Colour Table> component T of G shall have k
 <Primitive Colour> components.

 However, <Colour Table> components of a <Colour Table Group>
 are free to have different types of <Primitive Colour> components from
 each other (such as some using <Specular Colour>, some not).

Rationale:
 This is a requirement in order to allow the <Colour Table> instances
 within a <Colour Table Group> to be interchangeable.

Example:
 1. An <Colour Table Group> contains three <Colour Table> components: one
    for an Out-The-Window view, one for a RADAR view, and one for an
    Infra-Red view. All three <Colour Table> instances contain 234
    <Primitive Colour> components. Entry 234 in each <Colour Table>
    is a <Primitive Colour> for the representation of "granite" in the
    three different domains.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Connected Edge Restrictions

Definition:
 1. A <Feature Node> FN has the following relationship with its
    <Connected Feature Edge> components, if any exist.

    1.1. For each <Feature Edge> that has FN as a starting node,
         FN shall be associated to that <Feature Edge>.

    1.2. For each <Feature Edge> that has FN as an ending node,
         FN shall be associated to that <Feature Edge>.

    1.3. If FN is neither a starting nor an ending node of a given
         <Feature Edge>, FN shall not be associated to that
         <Feature Edge>.

    1.4. Consequently, for any given <Feature Edge> FE of which
         FN is a starting or ending node, FE shall appear among
         the associates of FN either:

         - once, if FN is FE's starting node and not its ending node,

         - once, if FN is FE's ending node and not its starting node,

         - twice, if FE is a loop.

 2. A <Geometry Node> GN has the following relationship with its
    associated <Geometry Edge> instances, if any.

    2.1. For each <Geometry Edge> that has GN as a starting node, GN shall be
         associated to that <Geometry Edge>.

    2.2. For each <Geometry Edge> that has GN as an ending node, GN shall be
         associated to that <Geometry Edge>.

    2.3. If GN is neither the starting nor ending node of a given <Geometry
         Edge>, GN shall not be associated to that <Geometry Edge>.

    2.4. Consequently, for any given <Geometry Edge> GE of which GN is a
         starting or ending node, GE shall appear among the associates of
         GN either:

          - once, if GN is GE's starting node and not its ending node;

          - once, if GN is GE's ending node and not its starting node; or

          - twice, if GE is a loop.

Rationale:
 The associations between <Feature Node> and <Feature Edge>
 implement a boundary/co-boundary relationship.  This topological
 relationship must be consistent, and must be consistent with the
 geometric representation of these objects.

 The associations between <Geometry Node> and <Geometry Edge>
 implement a boundary/co-boundary relationship.  This topological
 relationship must be consistent, and must also be consistent with the
 geometric counterparts of these objects.

Example:
 1. Consider a <Feature Edge> instance E1 that has distinct
    starting and ending <Feature Node> instances N1 and N2.
    N1 shall be associated to E1, and N2 shall also be
    associated to E1.

 2. Consider a <Geometry Edge> E1 that has distinct starting and ending
    <Geometry Node> instances N1 and N2. N1 shall be associated to E1,
    and N2 shall also be associated to E1.

FAQs:
 Q. For a <Feature Edge> that forms a loop (that is, a
    <Feature Edge> for which the starting <Feature Node>
    and ending <Feature Node> are the same <Feature Node>),
    how many times does that <Feature Edge> appear in that
    <Feature Node>'s list of associated <Feature Edge>
    instances?
 A. Twice, with opposite <Edge Direction> values.  A
    <Feature Edge> with distinct starting and ending
    <Feature Node> instances would appear only once.
 Q. For a <Geometry Edge> that forms a loop (that is, a <Geometry Edge>
    whose starting <Geometry Node> and ending <Geometry Node> are the
    same <Geometry Node>), how many times does that <Geometry Edge>
    appear in that <Geometry Node>'s list of associated <Geometry Edge>
    instances?
 A. Twice, with opposite <Edge Direction> values.  A <Geometry Edge> with
    distinct starting and ending <Geometry Node> instances would appear
    only once.

-------------------------------------------------------------------------------

Constraint Name: Contained Edge Restrictions

Definition:
 A <Feature Volume> instance FV has the following relationship
 with its associated <Feature Edge> instances, if any exist.
 At any feature topology level, if FV is associated with any
 <Feature Edge> instance FE, then FE shall lie completely within
 the external shell of FV, if any, and shall NOT lie within any
 of the internal shells of FV, if any.  Conversely, if a
 <Feature Edge> instance FE lies within the boundaries of FV, then
 FE shall be associated with FV.  If no <Feature Edge> instances
 lie within its boundaries, FV shall not be associated with
 any <Feature Edge> instances.

 A <Geometry Volume> GV has the following relationship with its
 associated <Geometry Edge> instances, if any exist.  At any
 geometry topology level, if GV is associated with any <Geometry Edge>
 instance GE, then GE shall lie completely within the interior of GV.
 Conversely, if a <Geometry Edge> instance GE lies completely within
 the interior of GV, then GE shall be associated with GV.  If no
 <Geometry Edge> instances lie completely within its interior, GV
 shall not be associated with any <Geometry Edge> instances.

Rationale:
 The association between <Feature Edge> and <Feature Volume>
 implements a containment relationship.  This topological
 relationship must be consistent, and must be consistent with
 the geometric representation of these objects.

 The association between <Geometry Edge> and <Geometry Volume>
 implements a containment relationship.  This topological relationship
 must be consistent, and must be consistent with the geometric
 counterparts of these objects.

Example:
 1. Consider a <Feature Edge> E1 that is "floating" within
    the interior of a <Feature Volume> V1.  E1 is contained
    within V1, and V1 contains E1.

 2. Consider a <Geometry Edge> E1 that is "floating" within the
    interior of a <Geometry Volume> V1.  E1 is contained within
    V1, and V1 contains E1.

FAQs:
 Q. If a <Feature Edge> is contained within the interior of
    a <Feature Volume>, must the <Feature Node> instances
    that bound that <Feature Edge> also be contained within
    the interior of that same <Feature Volume>?
 A. No.  The <Feature Node> instances that bound such a
    <Feature Edge> may be contained within the containing
    <Feature Volume>, or may be contained within the interior
    of one of the <Feature Face> instances that bound that
    <Feature Volume>, or may even be one of the
    <Feature Node> instances that bound one of the
    <Feature Edge> instances that in turn bound one of the
    <Feature Face> instances that bound that <Feature Volume>.
 Q. If a <Geometry Edge> is contained within the interior of a
    <Geometry Volume>, must the <Geometry Node> instances that bound
    that <Geometry Edge> also be contained within the interior
    of that same <Geometry Volume>?
 A. No.  The <Geometry Node> instances that bound such a <Geometry Edge>
    may be contained within the containing <Geometry Volume>,
    or may be contained within the interior of one of the
    <Geometry Face> instances that bound that <Geometry Volume>, or may
    even be one of the <Geometry Node> instances that bound one of the
    <Geometry Edge> instances that in turn bound one of the
    <Geometry Face> instances that bound that <Geometry Volume>.

-------------------------------------------------------------------------------

Constraint Name: Contained Node Restrictions

Definition:
 1. A <Feature Face> FF has the following relationship with its associated
    <Feature Node> instances, if any exist. At any feature topology level,
    if FF is associated with any <Feature Node> instance FN, then FN shall
    lie within the external ring of FF, if any, and shall NOT lie within any
    of the internal rings of FF, if any. Conversely, if a <Feature Node>
    FN lies within the boundaries of FF, then FN shall be
    associated with FF.  If no <Feature Node> instances lie within
    its boundaries, FF shall not be associated with any
    <Feature Node> instances.

 2. A <Feature Volume> FV has the following relationship with its
    associated <Feature Node> instances, if any exist.  At any
    feature topology level, if FV is associated with any
    <Feature Node> FN, then FN shall lie completely within the
    external shell of FV, if any, and shall NOT lie within any of
    the internal shells of FV, if any.  Conversely, if a
    <Feature Node> FN lies within the boundaries of FV, then FN
    shall be associated with FV.  If no <Feature Node> instances
    lie within its boundaries, FV shall not be associated with
    any <Feature Node> instances.

 3. A <Geometry Face> GF has the following relationship with its associated
    <Geometry Node> instances, if any.  At any geometry topology level, if
    GF is associated with any <Geometry Node> GN, then GN shall lie within
    the interior of GF.  Conversely, if a <Geometry Node> GN lies within the
    interior of GF, then GN shall be associated with GF.  If no <Geometry
    Node> instances lie within its interior, GF shall not be associated with
    any <Geometry Node> instances.

 4. A <Geometry Volume> GV has the following relationship with its associated
    <Geometry Node> instances, if any exist.  At any geometry topology
    level, if GV is associated with any <Geometry Node> GN, then GN shall
    lie within the interior of GV.  Conversely, if a <Geometry Node> GN lies
    within the interior of GV, then GN shall be associated with GV.
    If no <Geometry Node> instances lie within its interior, GV shall not be
    associated with any <Geometry Node> instances.

Rationale:
 The associations between <Feature Node> and <Feature Face>,
 and between <Feature Node> and <Feature Volume>, implement
 containment relationships.  These topological relationships
 must be consistent, and must be consistent with the
 geometric representations of these objects.

 The associations between <Geometry Node> and <Geometry Face>, and
 between <Geometry Node> and <Geometry Volume>, implement containment
 relationships.  These topological relationships must be consistent,
 and must be consistent with the geometric counterparts of these
 objects.

Example:
 1. Consider a <Feature Node> N1 that is "floating" within
    the interior of a <Feature Volume> V1.  N1 is contained
    within V1, and V1 contains N1.
 2. Consider a <Geometry Node> N1 that is "floating" within the
    interior of a <Geometry Volume> V1.  N1 is contained within V1,
    and V1 contains N1.

FAQs:
 Q. Can a <Feature Node> that is contained within the interior of a
    <Feature Face> or <Feature Volume> also be connected to one or more
    <Feature Edge> instances?
 A. Yes.  A <Feature Node> that is contained within the interior of
    a <Feature Face> can also be connected to a <Feature Edge>, as
    long as that <Feature Edge> does not bound that <Feature Face>.
    This is only possible within a three-dimensional
    spatial reference frame.  A <Feature Node> that is contained
    within the interior of a <Feature Volume> can also be connected
    to a <Feature Edge>, as long as that <Feature Edge> does not
    bound any of the <Feature Face> instances that in turn bound that
    <Feature Volume>.
 Q. Can a <Geometry Node> that is contained within the interior of a
    <Geometry Face> or <Geometry Volume> also be connected to one or
    more <Geometry Edge> instances?
 A. Yes.  A <Geometry Node> that is contained within the interior of
    a <Geometry Face> can also be connected to a <Geometry Edge>, as
    long as that <Geometry Edge> does not bound that <Geometry Face>.
    This is only possible within a three-dimensional
    spatial reference frame.  A <Geometry Node> that is contained
    within the interior of a <Geometry Volume> can also be connected
    to a <Geometry Edge>, as long as that <Geometry Edge> does not
    bound any of the <Geometry Face> instances that in turn bound that
    <Geometry Volume>.

-------------------------------------------------------------------------------

Constraint Name: Continuous LOD Restrictions

Definition:
 1. <Continuous LOD Related Geometry> instances can be used
    only in the scope of some <Environment Root> instance.

 2. A <Primitive Geometry> instanced within the component tree of a
    <Continuous LOD Related Geometry> shall not have
    a <Union Of Primitive Geometry> component.

Rationale:
 1. Nobody has flickering problems caused by zooming in on a <Model>
    instance.

 2. <Continuous LOD Related Geometry> instances always represent
    terrain, and terrain <Polygon> instances don't use subfacing.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Cylindrical Structure

Definition:
 1. For a <Cylindrical Volume Extent> instance C, the following conditions
    shall hold.

    1.1 The <Reference Vector> components of C shall comply with the
        restrictions imposed in the specification of the
        <Cylindrical Volume Extent> class, including the restrictions
        on their vector_type field values and their orientation relative
        to one another.

    1.2 If a <Reference Vector> component of C specifies a <Location>
        component L, L shall be the <Location 3D> specified by the
        volume context in which C appears.

 2. For an <Elliptic Cylinder> instance E, the following conditions shall
    hold.

    2.1 The <Reference Vector> components of E shall comply with the
        restrictions imposed in the specification of the
        <Elliptic Cylinder> class, including the restrictions
        on their vector_type field values and their orientation relative
        to one another.

    2.2 If a <Reference Vector> component of E specifies a <Location>
        component L, L shall be the <Location 3D> component of E.

Rationale:
 An instance of a DRM class representing a cylindrical volume shall
 specify a geometrically valid cylinder, and any <Location> information
 specified by its <Reference Vector> components shall be consistent with
 the context supplied by that volume.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Distinct Geometric Centre

Definition:
 If an instance of <Aggregate Geometry> specifies more
 than one <Geometric Centre> component, each shall
 specify a different value for its meaning field.

Rationale:
 At any given point in time, a body cannot have more than
 point serving as a specific <Geometric Centre>.

Example:
 1. Let G be the SEDRIS object that is the root of the
    geometric representation of a body B, such that G
    has a <Geometric Centre> representing B's
    SE_GEOM_CTR_CODE_CENTRE_OF_MASS. G cannot have
    another <Geometric Centre> component with meaning =
    SE_GEOM_CTR_CODE_CENTRE_OF_MASS, because no body B can
    have two different centres of mass at the same time.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Distinct Link Objects

Definition:
 1. Under any single <Aggregate Feature> or <Aggregate Geometry>
    instance, the link objects (if any) shall have non-identical
    discriminators.

 2. Under any single <Separating Plane Relations> instance, the
    link objects shall have non-identical discriminators.

 3. Under any single topology hierarchy, whether a
    <Feature Topology Hierarchy> or <Geometry Topology Hierarchy>, the
    link objects shall have non-identical discriminators.

 4. Under any single model instance, whether a <Feature Model Instance> or a
    <Geometry Model Instance>, the <Model Instance Template Index> instances
    shall be distinct.

Rationale:
 Discriminators shall be distinct in order to allow the user to
 discriminate between the branches they represent.

 However, this does not apply to link objects that exist only to specify
 sides of a <Separating Plane> instance.

 For model instances, the indices into the <Interface Template> instance
 shall be distinct because no <Variable> can be set to more than one
 value at a time.

Example:
 1. For a level-of-detail-related aggregation, no 2
    <Base LOD Data> may be identical.

 2. For a time-related aggregation, 2 <Time Constraints Data> may
    overlap, but not be identical.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Edges Bordering Faces

Definition:
 1. <Feature Edge> instances have the following relationship with
    <Feature Face> instances.

    At any topology level, if a <Feature Edge> FE associates to a
    <Feature Face> FF, then FF shall have a component
    <Feature Face Ring> that associates to FE.  Conversely, if a
    <Feature Face> FF has a component <Feature Face Ring> that
    associates to a <Feature Edge> FE, then FE shall also
    associate to FF.

 2. <Geometry Edge> instances have the following relationship with
    <Geometry Face> instances. At any topology level, if a
    <Geometry Edge> GE associates to a <Geometry Face> GF,
    then GF shall also associate to GE.  Conversely, if a
    <Geometry Face> GF associates to a <Geometry Edge> GE,
    then GE shall also associate to GF.

Rationale:
 The associations between <Feature Edge> and <Feature Face> implement
 a boundary/co-boundary relationship.  This topological relationship
 must be consistent, and must also be consistent with the geometric
 representations of these objects.

 The associations between <Geometry Edge> and <Geometry Face> implement
 a boundary/co-boundary relationship.  This topological relationship
 must be consistent, and must also be consistent with the geometric
 counterparts of these objects.

Example:
 1. A <Feature Face> F1 is bounded by two <Feature Edge> instances
    E1 and E2.  F1 is associated to both E1 and E2.  Also, E1 and
    E2 are both associated to F1.

 2. A <Geometry Face> F1 is bounded by two <Geometry Edge> instances
    E1 and E2.  F1 is associated to both E1 and E2.  Also, E1 and E2
    are both associated to F1.

FAQs:
 Q. Can a <Feature Edge> be associated with a <Feature Face> more
    than once?
 A. Yes.  A <Feature Edge> that "dangles" into the interior of a
    <Feature Face> will appear twice in the collection of
    <Feature Edge> instances that are associated with the exterior
    <Feature Face Ring> of that <Feature Face>, once with each
    orientation.  A <Feature Edge> that "floats" within the
    interior of a <Feature Face> will appear twice in the
    collection of <Feature Edge> instances that are associated
    with an interior <Feature Face Ring> of that <Feature Face>,
    once with each orientation.
 Q. Can a <Geometry Edge> be associated with a <Geometry Face>
    more than once?
 A. Yes.  A <Geometry Edge> that "dangles" into the interior of a
    <Geometry Face> will appear twice in the collection of
    <Geometry Edge> instances that are associated with that
    <Geometry Face> instance, once with each orientation.

-------------------------------------------------------------------------------

Constraint Name: Environment Root Spatial Reference Frame

Definition:
 Consider a <Transmittal Root> instance TR having one or more
 <Environment Root> instances as components.

 1) For TR, no two <Environment Root> instances may have identical
    spatial reference frame parameters.

 2) All <Location> instances appearing in the composition tree rooted
    at a given <Environment Root> instance shall be defined within the
    spatial reference frame of that <Environment Root> instance, unless
    such <Location> instances fall within the scope of an object that
    defines its own spatial reference frame, such as a <Property Grid>
    or <Image Anchor>.

 3) No <Location> instances under an <Environment Root> may be invalid
    within that spatial reference frame; they shall be either valid,
    or "extended".

Rationale:
 An <Environment Root> instance is the starting point for all objects in
 the same spatial reference frame in a transmittal.

 A <Location> instance is not fully defined unless it falls within the scope
 of an object specifying its spatial reference frame parameters (for example,
 an <Environment Root> or <Image Anchor> instance). A <Location> instance in
 another spatial reference frame (such as celestiomagnetic when the
 reference frame is celestiodetic) is therefore undefined.

Example:
 1. If an <Environment Root> instance's spatial reference frame is AUTM,
    no <Location> instances under that <Environment Root> may be invalid
    in AUTM; they shall be either valid, or "extended".

 2. Consider a transmittal spanning two consecutive UTM zones. The
    transmittal will have two <Environment Root> instances, one each
    of the two UTM zones.

FAQs:
 Q. Why does a <Property Grid> have its own spatial reference frame,
    independent of that of its <Environment Root>?
 A. The "griddedness" of spatial positions is dependent on the properties of
    the spatial reference frame in which they are defined. Coordinate
    conversions and transformations are not, in general, linear, so that a
    set of points that form a regular array of positions in one spatial
    reference frame may not be regular in another spatial reference frame.
    Therefore, in order to preserve "griddedness", a <Property Grid>
    specifies a spatial reference frame in which the data positions form
    a grid.

 Q. Why does an <Image Anchor> have its own spatial reference frame,
    independent of that of its <Environment Root>?
 A. As with the "griddedness" of <Property Grid> instances, an
    <Image Anchor> instance specifies a spatial reference frame in
    which the anchor points specify the desired texture mapping, so
    that it is preserved without distortion.

    In addition, an <Image Anchor> may be attached directly to an <Image>,
    in which case the <Image Anchor> would be outside the scope of any
    <Environment Root>.

-------------------------------------------------------------------------------

Constraint Name: Face Direction Levels 0 3

Definition:
 At feature topology levels 0 through 3, the front field of
 <Face Direction> shall always be SE_TRUE.

Rationale:
 Only when feature topology is 3-dimensional can a <Feature Face> be said to
 have both a front and a back side.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Face Ring Edge Consistency

Definition:
 The following restrictions apply.

 1. For each consecutive <Feature Edge> instance within a
    <Feature Face Ring> instance, and for each consecutive
    <Geometry Edge> instance within a <Geometry Face Ring> instance,
    the <Edge Direction> instance shall be consistent with the
    starting and ending nodes of the edge.

 2. A <Feature Edge> instance shall appear no more than twice in a
    <Feature Face Ring> instance, once with each orientation.

 3. A <Geometry Edge> instance shall appear no more than twice in a
    <Geometry Face Ring> instance, once with each orientation.

Rationale:
 Replicated information shall be consistent.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Faces Bordering Volumes

Definition:
 <Feature Face> instances have the following relationship with
 <Feature Volume> instances.  At any topology level, if a
 <Feature Face> FF associates to a <Feature Volume> FV, then
 FV shall have a component <Feature Volume Shell> that
 associates to FF.  Conversely, if a <Feature Volume> FV has
 a <Feature Volume Shell> that associates to a <Feature Face> FF,
 then FF shall also associate to FV.

 <Geometry Faces> have the following relationship with <Geometry
 Volumes>.  At any topology level, if a <Geometry Face> GF associates
 to a <Geometry Volume> GV, then GV shall also associate to GF.
 Conversely, if a <Geometry Volume> GV associates to a
 <Geometry Face> GF, then GF shall also associate to GV.

Rationale:
 The associations between <Feature Face> and <Feature Volume>
 implement a boundary/co-boundary relationship.  This topological
 relationship must be consistent, and must be consistent with the
 geometric representation of these objects.

 The associations between <Geometry Face> and <Geometry Volume>
 implement a boundary/co-boundary relationship.  A <Geometry Volume> is
 bounded by one or more <Geometry Faces>.  This topological relationship
 must be consistent, and must also be consistent with the geometric
 counterparts of these objects.

Example:
 1. A <Feature Volume> V1 representing a cube is bounded by
    six <Feature Face> instances F1 through F6.  V1 is
    associated to F1, F2, F3, F4, F5, and F6 via its
    exterior <Feature Volume Shell>.  Also, F1, F2, F3, F4,
    F5, and F6 are all associated to V1.
 2. A <Geometry Volume> V1 representing a cube is bounded by six
    <Geometry Faces> F1 through F6.  V1 is associated to F1, F2,
    F3, F4, F5, and F6. Also, F1, F2, F3, F4, F5, and F6 are all
    associated to V1.

FAQs:
 Q. Can a <Feature Face> instance be associated with a
    <Feature Volume> more than once?
 A. Yes.  A <Feature Face> that "dangles" into the interior
    of a <Feature Volume> will appear twice in the collection
    of <Feature Face> instances that are associated with the
    exterior <Feature Volume Shell> of that <Feature Volume>,
    once with each orientation.
 Q. Can a <Geometry Face> be associated with a <Geometry Volume>
    more than once?
 A. Yes.  A <Geometry Face> that "dangles" into the interior of a
    <Geometry Volume> will appear twice in the collection of
    <Geometry Faces> that are associated with that <Geometry Volume>,
    once with each orientation.

-------------------------------------------------------------------------------

Constraint Name: Feature Edge Restrictions

Definition:
 The following restrictions apply.

 1. The <Location> instances within a <Feature Edge> instance shall be
    distinct (that is, no two may have the same coordinates).

 2. <Feature Edge> instances may meet only at <Feature Node> instances,
    and <Feature Face> instances may meet only along one or more
    <Feature Edge> instances.

 3. At feature topology level 2 or higher, no <Feature Edge> instance
    may intersect with or overlap another <Feature Edge> instance.

 4. At feature topology level 3, each <Feature Edge> instance forms
    part of the boundaries of exactly two <Feature Face> instances.

Rationale:
 The path defined by the sequence of line segments which connect the
 consecutive <Location> instances that make up a <Feature Edge> instance
 shall not intersect or overlap itself.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Finite Element Mesh Structure

Definition:
 For a <Finite Element Mesh> instance F with a <Mesh Face Table>
 component M, the following conditions shall hold.

 1. Each <Vertex> component of F shall appear exactly once
    as a component of F.

 2. No two <Vertex> components of F shall occupy the same
    position in space.

 3. If F has a <Property Table> component P such that P's
    <Classification Data> classifies it as an
    ECC_MESH_NODE_PROPERTY_SET, P shall be the only <Property Table>
    component of F that is so classified, and shall have the structure
    specified in the definition of the <Finite Element Mesh> class for
    a <Property Table> of its classification.

 4. If F has a <Property Table> component P such that P's
    <Classification Data> classifies it as an
    ECC_MESH_FACE_PROPERTY_SET, P shall be the only <Property Table>
    component of F that is so classified, and shall have the structure
    specified in the definition of the <Finite Element Mesh> class for
    a <Property Table> of its classification.

 5. If F has a <Property Table> component P such that P's
    <Classification Data> classifies it as an
    ECC_MESH_SOLID_SET, P shall be the only <Property Table>
    component of F that is so classified, and shall have the structure
    specified in the definition of the <Finite Element Mesh> class for
    a <Property Table> of its classification.

 6. If F has a <Property Table> component P1 such that P1's
    <Classification Data> classifies it as an
    ECC_MESH_SOLID_PROPERTY_SET, P1 shall be the only <Property Table>
    component of F that is so classified, and shall have the structure
    specified in the definition of the <Finite Element Mesh> class for
    a <Property Table> of its classification.

Rationale:
 1. All the <Vertex> components of a <Finite Element Mesh> are
    required to be distinct in order to form a geometrically valid
    mesh.

 2. The components of a <Finite Element Mesh> are required to comply
    with the conditions specified in the definition of the
    <Finite Element Mesh> and <Mesh Face Table> classes.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Hierarchy Summary Constraints

Definition:
 1. An instance of <Hierarchy Summary Item> shall have a drm_class field
    value corresponding to either:
    - <Feature Hierarchy> or one of its subclasses
    - <Geometry Hierarchy> or one of its subclasses

 2. For any <Hierarchy Summary Item> instance B that is a component of
    another <Hierarchy Summary Item> instance A, the class represented by
    B's drm_class field value shall be defined as a formal component of A,
    and the multiplicity and multiplicity_meaning of B shall comply with
    the corresponding component relationship between the two classes.

 3. Consider an <Environment Root> instance ER.

    3.1 If ER has a <Geometry Hierarchy> component GH, ER shall have
        at most one <Hierarchy Summary Item> component HS_G for which the
        drm_class field corresponds to a <Geometry Hierarchy> subclass.
        If such a component instance HS_G exists, its field values
        shall comply with the following constraints.

        3.1.1 HS_G's drm_class shall match that of GH.

        3.1.2 HS_G's multiplicity_meaning shall be SE_HS_MLTPCTY_CODE_EXACT,
              and its multiplicity shall be 1.

    3.2 If ER does not have a <Geometry Hierarchy> component,
        ER shall not have any <Hierarchy Summary Item> component for
        which the drm_class field corresponds to a <Geometry Hierarchy>
        subclass.

    3.3 If ER has a <Feature Hierarchy> component FH, ER shall have
        at most one <Hierarchy Summary Item> component HS_F for which the
        drm_class field corresponds to a <Feature Hierarchy> subclass.
        If such a component instance HS_F exists, its field values
        shall comply with the following constraints.

        3.3.1 HS_F's drm_class shall match that of FH.

        3.3.2 HS_F's multiplicity_meaning shall be SE_HS_MLTPCTY_CODE_EXACT,
              and its multiplicity shall be 1.

    3.4 If ER does not have a <Feature Hierarchy> component,
        ER shall not have any <Hierarchy Summary Item> component for
        which the drm_class field corresponds to a <Feature Hierarchy>
        subclass.

 4. Consider a <Model> instance M.

    4.1 If M has a <Geometry Model> with a <Geometry Hierarchy> component GH,
        M shall have at most one <Hierarchy Summary Item> component
        HS_G for which the drm_class field corresponds to a
        <Geometry Hierarchy> subclass. If such a component instance HS_G
        exists, its field values shall comply with the following
        constraints.

        4.1.1 HS_G's drm_class shall match that of GH.

        4.1.2 HS_G's multiplicity_meaning shall be SE_HS_MLTPCTY_CODE_EXACT,
              and its multiplicity shall be 1.

    4.2 If M does not have a <Geometry Model> component, or its
        <Geometry Model> does not have a <Geometry Hierarchy> component,
        M shall not have any <Hierarchy Summary Item> component for
        which the drm_class field corresponds to a <Geometry Hierarchy>
        subclass.

    4.3 If M has a <Feature Model> with a <Feature Hierarchy> component FH,
        M shall have at most one <Hierarchy Summary Item> component
        HS_F for which the drm_class field corresponds to a
        <Feature Hierarchy> subclass. If such a component instance HS_F
        exists, its field values shall comply with the following
        constraints.

        4.3.1 HS_F's drm_class shall match that of FH.

        4.3.2 HS_F's multiplicity_meaning shall be SE_HS_MLTPCTY_CODE_EXACT,
              and its multiplicity shall be 1.

    4.4 If M does not have a <Feature Model> component, or its
        <Feature Model> does not have a <Feature Hierarchy> component,
        M shall not have any <Hierarchy Summary Item> component for
        which the drm_class field corresponds to a <Feature Hierarchy>
        subclass.

 5. All <Geometry Hierarchy> associates (or <Feature Hierarchy> associates)
    of a given <Hierarchy Summary Item> instance shall be instances of
    the class specified by its drm_class field value, and shall conform
    to the structure that it specifies.

Rationale:
 A <Hierarchy Summary Item> component of an <Environment Root>
 or <Model> exists to summarize a corresponding hierarchy of
 its aggregate. Consequently, its drm_class and multiplicity
 shall be consistent with the hierarchy which it represents.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Homogeneous Light Rendering Properties

Definition:
 A <Light Rendering Properties> shall contain instances of no more than one
 sub-class of <Directional Light Behaviour>.

Rationale:
 This is all that is currently required and avoids clashes over which
 <Directional Light Behaviour> defines the colour of the light when viewed
 from a particular direction.

Example:
 1. If a light has a conical lobe, it cannot also have a pyramid lobe.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Image Anchor Spatial Reference Frame

Definition:
 Consider an <Image Anchor> instance A.

 1. The <Location> instances in the scope of A shall be valid within
    the spatial reference frame specified by A's srf_info.

 2. A shall be either a component of one or more <Image> instances
    or of one or more <Image Mapping Function> instances, but not
    both.

 3. If A is a component of an <Image Mapping Function> instance F,
    and if F appears within the context of some spatial reference
    frame S, A's srf_info shall equal those specified by S.

Rationale:
 Every <Location> is required to be valid within the context of the
 spatial reference frame in which it is defined. (In this sense,
 "valid" includes the SRM concept of "extended" coordinates.) To
 allow an <Image Mapping Function> specified with an <Image Anchor>
 to be applied correctly to the textured objects, its
 spatial reference frame and theirs are required to be compatible.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Image Mapping Functions and Texture Coordinates

Definition:
 The number of <Image Mapping Function> instances referenced by a
 <Geometry Representation>
 instance shall equal the number of <Texture Coordinate> components for each
 <Vertex> and <Tack Point> instance within the SEDRIS object tree rooted at
 that <Geometry Representation> instance.

 <Image Mapping Function> instances referenced by <Feature Representation>
 instances, on
 the other hand, shall either have <Image Anchor> components, or reference
 <Image> instances that have <Image Anchor> components.

 EXCEPTION:
   If an <Image Mapping Function> instance is used to specify a
   non-planar projection (such as  spherical, cylindrical), it shall
   use an <Image Anchor> component, and the <Geometry Representation> instance to
   which the <Image Mapping Function> instance is attached cannot have
   <Texture Coordinate> or <Tack Point> instances within its component
   tree.

Rationale:
 The multiple <Image Mapping Function> and multiple <Texture Coordinate>
 instances are ordered, and are defined to correspond to each other as if
 they were in parallel arrays.

 <Image Mapping Function> instances referenced by <Feature Representation>
 instances are
 attributes for geometry that is to be derived by the consumer for the
 <Feature Representation>. Since <Texture Coordinate> and
 <Tack Point> instances are not
 applicable to <Feature Representation> instances, such
 <Image Mapping Function> instances
 shall be specified with <Image Anchor> components.

Example:
 1. Consider a triangular <Polygon> instance with one <Image Mapping Function>
    instance for the OTW (out-the-window) domain. Each of the <Polygon>
    instance's 3 <Vertex> components has one <Texture Coordinate> component,
    specifying the (s,t) within the image space that will be mapped to that
    <Vertex> instance.

                    <Polygon>
                       <>
     -----------------------------------------------
     |              |             |                |
    <Vertex>    <Vertex>      <Vertex>     <Image Mapping Function>
     <>            <>             <>               <>
     |              |             |                |
   <Texture     <Texture      <Texture     <Presentation Domain>
   Coordinate>   Coordinate>   Coordinate>  { OTW }

 2. Consider a triangular <Polygon> that has different texture maps, one
    for OTW and one for thermal. The <Polygon> thus has 2 ordered <Image
    Mapping Function> instances, so each of its <Vertex> components will have 2
    ordered <Texture Coordinate> components, one for each
    <Image Mapping Function> instance.

                    <Polygon>
                       <>
     --------------------------------------------------------------------
     |              |              |                                    |
    <Vertex>    <Vertex>       <Vertex>     <Image Mapping Function> ---|
     <>            <>              <>                  <>               |
     |              |              |                   |                |
     |-<Texture     |-<Texture     |-<Texture     <Presentation Domain> |
     |  Coordinate> |  Coordinate> |  Coordinate>  { OTW }              |
     |              |              |                                    |
     |-<Texture     |-<Texture     |-<Texture                           |
        Coordinate>    Coordinate>    Coordinate>                       |
                                                                        |
                                            <Image Mapping Function> ---|
                                                       <>
                                                       |
                                              <Presentation Domain>
                                               { Thermal }

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Index Codes within Tables

Definition:
 1. No <Property> instance, other than a <Table Property Description>,
    shall have an SE_Index_Code meaning value.

 2. Consider a <Data Table> instance DT, with a component
    <Table Property Description> instance X, where X has
    a meaning value of SE_INDEX_CODE_DATA_TABLE_LIBRARY.

    For each corresponding cell value N in the <Data Table>
    instance DT, if N is not a sentinel value for missing
    or excluded, N is an index into the ordered set
    of <Data Table> components of a <Data Table Library>
    where

    2.1 The transmittal in which the <Data Table> DT
        resides shall have a <Data Table Library> L,

    2.2 The <Data Table Library> L shall have at least
        N ordered <Data Table> components,

    2.3 The Nth <Data Table> component of the
        <Data Table Library> L shall have a
        <Classification Data>, the tag of which matches
        the component_data_table_ecc of the
        <Table Property Description> instance X.

        2.3.1 If the <Classification Data> of the
              referenced Nth <Data Table> has no
              component <Property Values>,
              the <Table Property Description> instance
              X shall have none.

        2.3.2 If the <Classification Data> of the
              referenced Nth <Data Table> has
              j component <Property Values>,
              the <Table Property Description> instance
              X shall have exactly j matching
              <Property Values>.

 3. Consider a <Data Table> instance DT, with a component
    <Table Property Description> instance X, where X has
    a meaning value of SE_INDEX_CODE_DATA_TABLE_COMPONENT.

    For each corresponding cell value N in the <Data Table>
    instance DT, if N is not a sentinel value for missing
    or excluded, N is an index into the ordered set
    of <Data Table> components of DT, where

    3.1 The <Data Table> DT shall have at least N ordered
        <Data Table> components,

    3.2 The Nth <Data Table> component of DT shall have a
        <Classification Data>, the tag of which matches the
        component_data_table_ecc of the
        <Table Property Description> instance X.

        3.2.1 If the <Classification Data> of the
              referenced Nth <Data Table> has no
              component <Property Values>,
              the <Table Property Description> instance
              X shall have none.

        3.2.2 If the <Classification Data> of the
              referenced Nth <Data Table> has
              j component <Property Values>,
              the <Table Property Description> instance
              X shall have exactly j matching
              <Property Values>.

 4. Consider a <Data Table> instance DT, with a component
    <Table Property Description> instance X, where X has
    a meaning value of SE_INDEX_CODE_PROP_TABLE_REF_COMPONENT.

    For each corresponding cell value N in the <Data Table>
    instance DT, if N is not a sentinel value for missing
    or excluded, N is an index into the ordered set
    of <Property Table Reference> components of DT, where

    4.1 The <Data Table> DT shall have at least N ordered
        <Property Table Reference> components,

    4.2 The Nth <Property Table Reference> component of DT
        shall refer to a <Property Table> such that its
        <Classification Data> tag matches
        the component_data_table_ecc of the
        <Table Property Description> instance X.

        4.2.1 If the <Classification Data> of the referenced
              <Property Table> has no component <Property Values>,
              the <Table Property Description> instance
              X shall have none.

        4.2.2 If the <Classification Data> of the referenced
              <Property Table> has j component <Property Values>,
              the <Table Property Description> instance
              X shall have exactly j matching
              <Property Values>.

 5. A <Table Property Description> instance which is not
    covered by 2, 3, or 4 above shall have no <Property Value>
    components.

 6. Consider a <Data Table> instance DT, with a component
    <Table Property Description> instance X, where X has
    a meaning value of SE_INDEX_CODE_IMAGE_MAPPING_FUNCTION.

    For each corresponding cell value N in the <Data Table>
    instance DT, if N is not a sentinel value for missing
    or excluded, N is an index into the ordered set
    of <Image Mapping Function> components of DT, where
    the <Data Table> DT shall have at least N ordered
    <Image Mapping Function> components.

Rationale:
 1. The SE_Index_Code enumerants that exist to allow cells within
    <Data Table> instances to reference <Data Table Library>
    component <Data Table>, component <Data Table>, component
    <Property Table References>, and component <Image Mapping Function>
    instances are meaningless for all other <Property> contexts.

 2. The only function of <Property Value> components for the
    <Table Property Description> class to provide elaboration for
    the meaning field as needed, since in general, referenced
    <Data Table> instances are distinguished only by their
    classification (which may be elaborated).

Example:
 1. Consider a <Property Table> instance containing two
    <Table Property Description> instances defining indices to sub-tables
    (that is, two elements in each cell are such indices, and the
    <Property Table> itself has two component <Property Table> instances).

    The first index references sub-tables classified by
    ECC_WATER_BODY_ACOUSTIC_PROPERTY_SET with <Property Value>
    elaboration EAC_FREQUENCY = 100 Hz.

    The second index references sub-tables classified by
    ECC_WATER_BODY_ACOUSTIC_PROPERTY_SET with <Property Value>
    elaboration EAC_FREQUENCY = 2000 Hz.

    <Property Table>
     <>
     |
     |
     |---- <Table Property Description>
     |     meaning =
     |        { SE_ELEM_CODE_TYP_INDEX,
     |          { SE_INDEX_CODE_DATA_TABLE_COMPONENT }}
     |      <>
     |      |
     |     <Classification Data>
     |     ECC_WATER_BODY_ACOUSTIC_PROPERTY_SET
     |      <>
     |      |
     |      |---- <Property Value>
     |      |     meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
     |      |                 { EAC_PROPERTY_SET_SPATIAL_DOMAIN }
     |      |     value = { EDCS_AVT_ENUMERATION,
     |      |               { EEC_PRPSETSPATDMN_SURFACE }}
     |      |
     |      |---- <Property Value>
     |      |     meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
     |      |                 { EAC_WATER_BODY_PROPERTY_SET_ACOUSTIC_TYPE }
     |      |     value = { EDCS_AVT_ENUMERATION,
     |      |               { EEC_WTRBDPRPSTACTY_LOSS }}
     |      |
     |      |---- <Property Value>
     |            meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
     |                        { EAC_FREQUENCY }
     |            value       = { EDCS_AVT_REAL,
     |                            { EUC_HERTZ, ESC_UNI,
     |                              { EDCS_NVT_SINGLE_VALUE, { 100.0 } }
     |                            }
     |                          }
     |
     |
     |---- <Table Property Description>
           meaning =
              { SE_ELEM_CODE_TYP_INDEX,
                { SE_INDEX_CODE_DATA_TABLE_COMPONENT }}
            <>
            |
           <Classification Data>
           ECC_WATER_BODY_ACOUSTIC_PROPERTY_SET
            <>
            |
            |---- <Property Value>
            |     meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
            |                 { EAC_PROPERTY_SET_SPATIAL_DOMAIN }
            |     value = { EDCS_AVT_ENUMERATION,
            |               { EEC_PRPSETSPATDMN_SURFACE }}
            |
            |---- <Property Value>
            |     meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
            |                 { EAC_WATER_BODY_PROPERTY_SET_ACOUSTIC_TYPE }
            |     value = { EDCS_AVT_ENUMERATION,
            |               { EEC_WTRBDPRPSTACTY_LOSS }}
            |
            |---- <Property Value>
                  meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
                              { EAC_FREQUENCY }
                  value       = { EDCS_AVT_REAL,
                                  { EUC_HERTZ, ESC_UNI,
                                    { EDCS_NVT_SINGLE_VALUE, { 2000.0 } }
                                  }
                                }

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Legal Time Ranges

Definition:
 1. For <Absolute Time>, (when hour, minutes, and/or seconds exist)
    1.1 hour shall be between 0 and 23 inclusive.
    1.2 minutes shall be between 0 and 59 inclusive.
    1.3 seconds shall be between 0 and 60; that is, 0.0 <= seconds < 60.0.

 2. For <Absolute Time Interval> and <Relative Time>,
    2.1 delta_hours shall be between 0 and 23 inclusive.
    2.2 delta_minutes shall be between 0 and 59 inclusive.
    2.3 delta_seconds shall be between 0 and 60;
        that is, 0.0 <= delta_seconds < 60.0.

 3. For <Relative Time Interval>,
    3.1 delta_start_hours shall be between 0 and 23 inclusive, and
        delta_stop_hours shall be between 0 and 23 inclusive.
    3.2 delta_start_minutes and delta_stop_minutes shall each be between 0
        and 59 inclusive.
    3.3 delta_start_seconds and delta_stop_seconds shall each be between 0
        and 60; that is, 0 <= seconds < 60.0.

Rationale:
 Any values for hour greater than 23 should be expressed in days.

 Any values for minutes greater than 59 should be expressed in hours.

 Any values for seconds greater than or equal to 60 should be
 expressed in minutes.

Example:
 1. To specify a date of 31 December 1999 with an <Absolute Time>
    instance,
    time_value.value.time_configuration SE_TIME_CONFIGURATION_DATE_YMD
    time_value.value.ymd.year           1999
    time_value.value.ymd.month          SE_MONTH_DECEMBER
    time_value.value.ymd.day            31

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: LOD Related Organizing Principle

Definition:
 For any level-of-detail related organization LRO, whether a
 <LOD Related Features> or <LOD Related Geometry>,

 1. The <Base LOD Data> for each branch of LRO shall match
    the class specified by LRO's lod_data_type field.

 2. For each pair of branches, if the <Base LOD Data> instances
    overlap, neither shall be a subset of the other.

    2.1 For two <Distance LOD Data> instances, neither interval
        shall be contained within the other. Specifically,

        2.1.1 The ranges may touch at their endpoints; that is, the
              minimum_range of one may equal the maximum_range of
              the other.

        2.1.2 If the ranges overlap by more than one endpoint,
              each shall have at least one fade band, so that one is
              fading in while the other is fading out for the
              overlap range.

    2.2 For two <Volume LOD Data> instances,

        2.2.1 If the two branches both have outside = SE_FALSE,
              neither volume may be contained within the other.

        2.2.2 The volumes specified may be identical if the link
              objects specify different values for their outside
              fields, provided that LRO complies with
              <<Distinct Link Objects>>.

 3. If LRO inherited a <Base LOD Data> instance C as a
    component, such that C matches its lod_data_type, LRO's
    link objects shall fall within the scope specified by C.

    3.1 If C is a <Distance LOD Data> instance and LRO is
        SE_LOD_DATA_TYP_DISTANCE, each link object
        specified by LRO shall specify a range within the
        region covered by C.

    3.2 If C is a <Volume LOD Data> instance and LRO is
        SE_LOD_DATA_TYP_VOLUME, each link object specified
        by LRO shall specify a volume lying within that of C.

    3.3 No other classes of C permit a matching LRO to occur
        in their inheritance tree.

Rationale:
 1. The mechanism for switching between different levels of detail is
    defined only if the "type" of level of detail is homogeneous.

 2. Different branches of a level-of-detail related organization can
    be active at the same time only if one is incoming and the other
    is outgoing.

 3. The component tree of an item with level-of-detail information
    shall comply with that level-of-detail.
    3.1 If a hierarchy is visible only from viewing distance X to
        viewing distance Y, none of its components can be
        visible outside that range.

    3.2 If a hierarchy is visible only inside (or outside) a given
        viewing volume, all of its components are also inside
        (or outside) the given viewing volume.

    3.3 If a hierarchy is visible only at a specific index,
        map scale, or spatial resolution, none of its components
        can be visible at any conflicting value.

Example:
 1. It isn't defined for a data provider to switch between
    - "0-500 metres" for <Distance LOD Data> and
    - "sphere with radius 5 metres centred at 0, 0, 0" for
      <Volume LOD Data>.

 2. Range-based components and index-based components will not
    be attached to the same <LOD Related Geometry> instance.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Linear Geometry Structure

Definition:
 For a <Linear Geometry> instance G (that is, an instance of one of the
 concrete subclasses of <Linear Geometry>, the following conditions
 shall hold.

 1. Each <Vertex> component of G shall appear exactly once as a
    component of G.

 2. No two <Vertex> components of G shall occupy the same position
    in space.

 3. If G is an instance of <Arc>, the <Location> component of G shall
    not occupy the same position in space as any of the <Vertex>
    components of G.

 4. For any <Geometry Edge> instance E associated with G, the
    <Geometry Node> instances forming the endpoints of E shall be
    associated with <Vertex> components of G.

Rationale:
 The <Location> information of a <Linear Geometry> instance is required
 to be distinct in order to form geometrically valid <Linear Geometry>.

Example:
 1. An <Arc>, in order to specify a geometric arc, is required to have
    distinct endpoints, and the <Location> about which it is symmetric
    is required to be distinct from those endpoints for the same reason.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: LSR Transformation Components

Definition:
 An <LSR Transformation> instance L shall have a <Local 4x4>, an ordered
 set of <LSR Transformation Step> components, or both. If L
 has both a <Local 4x4> and a set of <LSR Transformation Step> components,
 the ordered set of <LSR Transformation Step> components shall be
 mathematically equivalent to the <Local 4x4>.

Rationale:
 An <LSR Transformation> has 2 possible representations: as a <Local 4x4>,
 or as an ordered set of <LSR Transformation Step> components. If the
 <LSR Transformation> uses both, then the <Local 4x4> and the
 <LSR Transformation Step> components are alternate representations of
 the same transformation, so they shall be mathematically equivalent. If
 the <LSR Transformation> uses neither representation, then no transform
 is present, which means the <LSR Transformation> should not exist.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Mandatory Metadata

Definition:
 The following table lists meta-data classes. When these classes are
 instanced, at least the designated fields shall be populated.

 CLASS               MANDATORY FIELDS

 <Access>            The classification portion of the security field
                     shall be a non-empty string.

                     Consider an <Access> instance A.

                      - If A's access_constraints is set to
                        OTHER_RESTRICTIONS, A's other_constraints field
                        shall contain a non-empty string specifying what
                        those other restrictions are.

                      - If A's use_constraints is set to OTHER_RESTRICTIONS.
                        A's other_constraints field shall contain a non-empty
                        string specifying what those other restrictions are.

 <Browse Media>      name shall be a non-empty string

                     media_urn shall be a non-empty string in the
                     form of a valid URN

 <Citation>          title shall be a non-empty string

 <Description>       abstract shall be a non-empty string

                     An instance of <Description> that is a component of
                     a <Transmittal Root> shall have at least one <Keywords>
                     component.

 <Keywords>          All the <Keywords> components of a given object
                     instance shall have distinct type codes. Within
                     a given <Keywords> instance, the entries of the
                     keyword_array shall be distinct.

 <Lineage>           An instance of <Lineage> shall specify at least one
                     of the following:

                       - a <Process Step>,
                       - a <Source>, or
                       - a non-empty string within its statement field.

 <Resposible Party>  email_address shall be a non-empty string (still
                     complies with existing constraint that it's a
                     syntactically valid email address)

                     (still complies with the existing constraint that
                     the web_site, now the online_resource's location,
                     shall specify a syntactically valid URL)

                     The locale of each SE_String field shall be specified
                     using the same country code as that used by the address,
                     except that email_address entries shall be syntactically
                     valid email addresses (with locales set accordingly).

                     At least one of the following fields shall contain a
                     non-empty string: individual_name, position_name, or
                     organization_name.

 <Process Step>      description shall be a non-empty string

                     Given an instance P of <Process Step>, the following
                     conditions shall hold.

                       - P's description field shall be a non-empty string.

                       - P's <Absolute Time Point> component shall have
                         time_significance = SE_TIME_SIGNIF_OCCURRENCE.

                       - If P has <Responsible Party> components, each shall
                         specify SE_TIME_SIGNIF_PROCESSOR as its role.

                     RATIONALE:

                       - For an instance P of <Process Step>, P's description
                         field is required to be non-empty so that the
                         event is at least minimally described by its
                         representation P.

                       - P's <Absolute Time Point> component represents the
                         time at which the event represented by P occurred,
                         so its time_significance's semantic meaning is that
                         corresponding to SE_TIME_SIGNIF_OCCURRENCE.

 <Source>            description shall be a non-empty string

Rationale:
 This is consistent with the ISO/DIS 19115 Metadata
 Standard.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Model Reference Type Constraints

Definition:
 1. If an instance of <Model> has model_reference_type set to
    SE_MDL_REF_TYP_ROOT or SE_MDL_REF_TYP_ROOT_AND_COMPONENT, then the
    <Model> instance's name shall be unique in the scope of its
    aggregate <Model Library>.

 2. If an instance of <Model> has model_reference_type set to
    SE_MDL_REF_TYP_COMPONENT, then

    2.1 any <Geometry Model Instance> or <Feature Model Instance>
        referencing that <Model> shall be in the scope of another
        <Model> instance,

    2.2 its dynamic_model_processing flag shall be SE_FALSE.

Rationale:
 1. The model_reference_type of <Model> indicates whether a given
    instance can be instanced as a free-standing object, as a
    component of another <Model>, or both.

 2. All potentially free-standing <Model> instances within the
    scope of a given <Model Library> instance are required to
    have unique names, so that such <Model> instances can be
    unambiguously and easily identified.

 3. A <Model> that cannot be instanced as a free-standing
    object can only be referenced within other <Model> instances.

 4. The dynamic_model_processing flag of <Model> is used only
    at the "top" level of <Model> data, that is, at the level
    where a <Model> instance represents a free-standing
    object.

Example:
 1. Consider a <Model Library> instance ML which contains a <Model>
    with name set to  "plane" and model_reference_type set to
    SE_MDL_REF_TYP_ROOT. The name "plane" cannot be used for any
    any other <Model> in ML.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Model Spatial Reference Frame

Definition:
 1. Consider a <Model> M defined in a spatial reference frame other than
    Local Space Rectangular.

    1.1 M shall be instanced only by <Geometry Model Instance> and / or
        <Feature Model Instance> instances specified in a matching
        spatial reference frame, and

    1.2 M's has_moving_parts field shall be set to SE_FALSE.

 2. Consider a <Model> M defined in a Local Space Rectangular
    spatial reference frame.

    2.1 If M's has_units field is set to SE_FALSE, then M shall not
        be referenced by any <Geometry Model Instance> or
        <Feature Model Instance>.

    2.2 If M is to be instanced into a non-LSR reference frame by any
        <Geometry Model Instance> or <Feature Model Instance>, then
        each such <Geometry Model Instance> and <Feature Model Instance>
        shall specify a <World Transformation> component.

    2.3 M cannot be instanced into another Local Space Rectangular
        reference frame unless the target spatial reference frame
        has identical parameters to that of M.

    2.4 If the component hierarchy of M contains any
        <LSR Transformation> instances that have <Control Link>
        instances, and if M provides controlling <Variables> to those
        <Control Link> instances such that they allow motion,
        then M's has_moving_parts field shall be set to SE_TRUE;
        otherwise, M's has_moving_parts field shall be set to
        SE_FALSE.

    2.5 M shall not contain any <Reference Surface> instances.

 3. All <Location> instances under a <Model> instance shall be expressed
    in the spatial reference frame defined by that <Model> instance.

Rationale:
 1. A <Location> instance is not fully defined unless it falls within the
    scope of an object specifying its spatial reference frame parameters
    (such as a <Model>). A <Location> in another spatial spatial reference
    (such as geomagnetic (GM) when the reference frame is geodetic (GD)) is
    therefore undefined.

 2. <Transformation> instances are required when a model instancing
    operation requires actual coordinate transformation or conversion.

 3. A <Model> with moving parts is a <Model> containing parts that
    are attached by <LSR Transformation> instances with appropriate
    <Variable>-controlled <Control Links>, because that is how
    rotation, translation, and scaling are controlled dynamically.
    Consequently, such a <Model> is always defined in an LSR
    spatial reference frame, because <LSR Transformation> instances
    only appear in LSR.

 4. The intent of the constraint on LSR <Model> instances and
    <Reference Surface> instances is to limit the level of complexity
    for a transmittal consumer.  If and when the SEDRIS API directly
    supports elevation resolution for <Location 2D> instances, this
    constraint may be modified.

Example:
 1. A <Model> instance defined in a geodetic spatial reference frame may
    only be instanced within an <Environment Root> instance with matching
    geodetic spatial reference frame parameters.

 2. A <Geometry Model Instance> instance in a geodetic reference frame
    shall have a <World Transformation> component in order to instance a
    <Model> instance specified in a Local Space Rectangular reference frame.

 3. If a <Model> instance's spatial reference frame is LSR (2D or 3D), all
    <Location> instances under that <Model> instance shall be LSR (2D or 3D).

 4. Consider a <Model> instance defined in a 3D LSR spatial reference frame,
    such that it references a <Geometry Model Instance> instance via an
    <LSR Transformation> instance.

FAQs:
 Q. Are model <Location> instances restricted to LSR and the
    spatial reference frames found in a transmittal's <Environment Root>
    instances?
 A. No.  A <Model Library> instance might be designed to be part of a
    multi-transmittal environment with <Geometry Model Instance>
    or <Feature Model Instance> instances occurring in other transmittals,
    so that the transmittal containing the <Model Library> instance itself
    might not have any <Environment Root> instances at all.

 Q. Why aren't model instance objects required to have <Transformation>
    components in all cases?
 A. If no coordinate conversion or transformation is required between
    spatial reference frames, and if (for LSR) the model instance is
    not being rotated or translated within the target spatial reference
    frame, then a <Transformation> is unnecessary.

 Q. How is the elevation resolved for an <LSR 2D Location> instance in an
    LSR <Model> instance?
 A. As explained in <Reference Surface>'s FAQ list, when an <LSR 2D Location>
    is instanced, it is converted to a <Location 2D> in the scoping 3D SRF.
    Its elevation can then be determined in the 3D SRF.

-------------------------------------------------------------------------------

Constraint Name: Nested Primitive Geometry

Definition:
 When a <Primitive Geometry> contains a <Union Of Primitive Geometry> for
 nesting reasons, the resulting geometry shall be coplanar. Only <Polygon>,
 <Ellipse>, <Line>, <Arc>, and <Point> <Primitive Geometry> can have
 nesting, except for <Elliptic Cylinder> with <Finite Element Mesh>
 (see below).

 The possible combinations at any level of nesting are as follows.

 CLASS                PRIMITIVE GEOMETRIES THAT CAN BE NESTED

 <Polygon>            <Polygon>
                      <Ellipse>
                      <Line>
                      <Arc>
                      <Point>
                      <Finite Element Mesh>

 <Ellipse>            <Polygon>
                      <Ellipse>
                      <Line>
                      <Arc>
                      <Point>
                      <Finite Element Mesh>

 <Line>               <Line>
                      <Arc>
                      <Point>

 <Arc>                <Line>
                      <Arc>
                      <Point>

 <Point>              <Point>

 <Elliptic Cylinder>  <Finite Element Mesh> as an interior 3-D mesh

 <Finite Element Mesh> cannot nest.

Rationale:
 When a <Primitive Geometry> contains a <Union Of Primitive Geometry> for
 nesting reasons, the relationship means that the union represents a
 "subface" of the <Primitive Geometry>, i.e., it is part of the
 <Primitive Geometry>.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: No Attribute Conflicts

Definition:
 1. No two directly attached <Property Value> components of an object instance
    may specify identical values for their meaning fields.

    If an inherited <Property Value> has the same meaning field value as a
    directly attached <Property Value>, then the directly attached component
    replaces the inherited component in the inheritance context.

 2. No two directly attached <Property Description> components of an object
    instance may specify identical values for their meaning fields.

    If an inherited <Property Description> has the same meaning field value
    as a directly attached <Property Description>, then the directly
    attached component replaces the inherited component in the inheritance
    context.

Rationale:
 The intent of this constraint is eliminate ambiguity in specifying the
 attributes of an object instance.

Example:
 1. Consider a <Union Of Primitive Geometry> instance that is a collection
    of <Polygon> instances representing a parking lot that is primarily
    surfaced with asphalt but has a few patches of concrete.

    The <Union Of Primitive Geometry> instance has a <Property Value>
    component with
    meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
                { EAC_PRIMARY_MATERIAL_TYPE }} and its value is
    EEC_PRIATTY_ASPHALT. This is inherited by all the <Polygon> components
    of the union, so that if a <Polygon> instance represents a section of
    asphalt, it need not specify any further information.

    Consider a <Polygon> component in the union which represents one of
    the areas of concrete. This <Polygon> instance has a <Property Value>
    component which also has
    meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
                { EAC_PRIMARY_MATERIAL_TYPE }}
    but with value EEC_PRIATTY_CONCRETE. For that <Polygon> instance, the
    EEC_PRIATTY_CONCRETE value overrides the inherited
    EEC_PRIATTY_ASPHALT value.

                <Union Of Primitive Geometry>
                          <>
                          |
                          |----------------
                          |               |
                       <Polygon>    <Property Value>
                          <>        meaning =
                          |          { SE_PROP_CODE_TYP_ATTRIBUTE,
                          |           { EAC_PRIMARY_MATERIAL_TYPE }}
                          |         value = { EDCS_AVT_ENUMERATION
                          |                   { EEC_PRIATTY_ASPHALT }}
                          |
                     <Property Value>
                     meaning = { SE_PROP_CODE_TYP_ATTRIBUTE,
                                 { EAC_PRIMARY_MATERIAL_TYPE }
                     value.value_type = EDCS_AVT_ENUMERATION
                     value.u.ee_code = EEC_PRIATTY_CONCRETE

FAQs:
 Q. As a producer, I have a <Model> of a building which can be used for
    a police station or a post office.  Can both EAC_BUILDING_FUNCTION
    values be attached to the <Model> via two <Property Value>
    components? Or can both <Property Value> components be attached to the
    <Model>'s <Classification Data>?
 A. No. Instead, do the following.
    1. Produce the building <Model> as a component <Model> in the
       <Model Library>. (That is, set the <Model>'s model_reference_type
       field to SE_MDL_REF_TYP_COMPONENT.)

    2. Add a separate model to the <Model Library> for the police station,
       with a <Classification Data> tagged as EDCS_ECC_BUILDING and having
       an elaborating <Property Value> of
       EAC_BUILDING_FUNCTION, EEC_BLDGFN_POLICE_STATION.

       The <Geometry Model>'s <Geometry Hierarchy> (and/or
       <Feature Model>'s <Feature Hierarchy>, as the case may be) is just
       a <Geometry Model Instance> (or <Feature Model Instance>) which
       instances the building component model in (1), above.

    3. Similarly, add a separate model to the <Model Library> for the
       post office.

-------------------------------------------------------------------------------

Constraint Name: Non Crossing Aggregations

Definition:
 Aggregations shall not cross <Model> instances and/or
 <Environment Root> instances.

Rationale:
 Why would a generic <Model> use pieces of the terrain? If the <Model>
 is intended to be instanced as part of the terrain of the <Environment
 Root>, then <Environment Root> should instance the <Model>, not duplicate
 parts of it.

 If a <Model> instance or an <Environment Root> instance needs to use an
 instance of another <Model>, use a <Feature Model Instance> or a
 <Geometry Model Instance>. If only a portion of the <Model> is desired
 for reuse, that portion should be a <Model> of its own.

Example:
 1. If a <Polygon> is under <Environment Root>, no <Model> can use the
    <Polygon>.

 2. If a <Polygon> is under a <Model>, <Environment Root> cannot use
    the <Polygon> directly. A <Model>'s components can be accessed only
    via <Geometry Model Instances> and/or <Feature Model Instances>.

 3. If a <Polygon> is under a <Model>, no other <Model> can use that
    <Polygon> directly. A <Model>'s components can be accessed only
    via <Geometry Model Instances> and/or <Feature Model Instances>.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Non Crossing Associations

Definition:
 Associations shall not cross <Models> and/or <Environment Root>, except for
 <Geometry Model Instance> to <Geometry Model>, and
 <Feature Model Instance> to <Feature Model>.

Rationale:
 Consider the <Feature Representation> with <Geometry Hierarchy>
 association. This association means that the <Feature Representation> is an
 alternate representation of the <Geometry Hierarchy>. A terrain
 <Feature Representation> represents some part of
 the terrain, not a part of some <Model>; a <Model> feature represents
 some abstraction of the <Model> rather than a feature of the terrain.

Example:
 1. Consider a transmittal with an <Environment Root> and <Model Library>.
    Let "F15" be a <Model> in the <Model Library>, under which <Polygon>
    instances exist. No <Feature Representation> under the <Environment Root>
    may associate with an "F15" <Polygon>, since a terrain
    <Feature Representation> cannot at the same time represent a
    generic "F15" <Polygon>.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Non Cyclic Aggregations

Definition:
 Aggregations are not allowed to form cycles, although associations are.

Rationale:
 When an object is instanced, the object shall be constructed in such
 a way that a consumer can finish traversing it.

 Aggregations represent "has-a" relationships, where a component is part
 of the aggregation, e.g. an instance of a wall's <Geometry Model> is part
 of a building's <Geometry Model>. It doesn't make sense to say that
 component A is a proper subset of aggregation B, and then allow B to be a
 component of A.

 Associations, however, often mean that the associated objects are alternate
 representations of each other, as in, A is an alternate representation of B,
 so B is an alternate representation of A.

Example:
 1. It is not useful to say that a <Geometry Model Instance> of a bridge is
    part of itself.

 2. It is useful to say that a <Point Feature> represents an instance of a
    building <Model>, and that a <Geometry Model Instance> is really a
    building at a particular location.

FAQs:
 Q. Can an object A associate to B, which in turn associates to A?
 A. Yes, if the requisite relationships are syntactically legal.

 Q. Can an object have itself as a component?
 A. No.

 Q. Can an object associate to itself if the DRM allows instances
    of its class to associate to one another?
 A. Yes, although that doesn't provide any useful information.

-------------------------------------------------------------------------------

Constraint Name: Non Empty Environment Root

Definition:
 An <Environment Root> shall have either a <Feature Hierarchy>, a <Geometry
 Hierarchy>, or both.

Rationale:
 An <Environment Root> is optional in a transmittal, but a "vacuous"
 <Environment Root> is not permitted.  The DRM notation cannot enforce an
 "or" aggregation.  Consequently, this constraint is required.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Non Empty Model

Definition:
 1. All <Model> instances shall have either a <Feature Model>,
    a <Geometry Model>, or both.

 2. A <Model> is permitted to have an "empty" <Geometry Model>,
    that is, a <Geometry Model> without a component
    <Geometry Hierarchy>, only if

    2.1 The <Model> either does not have a <Feature Model>,
        or its <Feature Model> is "empty".

    2.2 The <Model> has a <Classification Data> component
        with tag = ECC_OBJECT

    2.3 The <Model> is tagged as SE_MDL_REF_TYP_ROOT_AND_COMPONENT
        so that it can be instanced within <Environment Root>
        scopes as well as other <Models>, and

    2.4 The "empty" <Geometry Model> has no <Attachment Point>,
        <Contact Point>, or <LSR Transformation> component,
        since these components require the presence of a
        <Geometry Hierarchy>).

 3. A <Model> is permitted to have an "empty" <Feature Model>,
    that is, a <Feature Model> without a component
    <Feature Hierarchy>, only if

    3.1 The <Model> either does not have a <Geometry Model>,
        or its <Geometry Model> is empty.

    3.2 The <Model> has a <Classification Data> component
        with tag = ECC_OBJECT.

    3.3 The <Model> is tagged as SE_MDL_REF_TYP_ROOT_AND_COMPONENT
        so that it can be instanced within <Environment Root>
        scopes as well as other <Models>.

 4. No <Model> other than a properly constructed "empty"
    <Model> is permitted to have a <Classification Data>
    with ECC_OBJECT.

Rationale:
 The DRM notation cannot enforce an "or" aggregation. Consequently, this
 constraint is required.

 Allowing a <Feature Model> to be empty permits a <Feature Model Instance>
 to associate to an "empty" <Feature Model>. The semantic restrictions
 on "empty" models will only have to be performed at the model level,
 rather than at model instance objects all over the transmittal.

 Allowing a <Geometry Model> to be empty permits a <Geometry Model Instance>
 to associate to an "empty" <Geometry Model>. The semantic restrictions
 on "empty" models will only have to be performed at the model level,
 rather than at model instance objects all over the transmittal.

Example:
     None.

FAQs:
 Q. How do these restrictions ensure that an "empty" <Model>
    can be distinguished from, e.g. an ordinary <Model> retrieved
   while ignoring ITR referenences?

 A. An "empty" <Model> shall have the required <Classification Data>
    component with ECC_OBJECT. Since its components, and
    their component hierarchies are required to be stored
    in the same transmittal, ITR references are not a concern.

 Q. As a data provider, when I am creating a <Model Library>,
    I don't know in advance whether I'll need an empty <Geometry
    Model>. I don't want to produce an "empty" <Model> if I
    don't need one; if I do need one, I'd prefer to make it the
    last <Model> in the <Model Library> to avoid changing the
    ID fields of the non-empty <Models>. How can I create
    forward references to an "empty" <Model> that hasn't been
    created yet?

 A. This question has more than one possible answer. One
    approach is to use reference symbols when using the
    level 0 API to produce your transmittal. This would allow
    you to take the following approach.
    (1) Create a reference symbol, representing the empty
        model.
    (2) Begin producing models for your model library.
        When you encounter a place in the <Model> where
        you need a <Geometry Model Instance> of the empty <Model>,
        a) create the <Geometry Model Instance>.
        b) add a symbolic association to the reference symbol
           that represents the empty <Model>
        c) trip a flag indicating that the empty <Model>
           is in use
    (3) Check the flag to see if the empty <Model> is
        being used, when you have created the last non-empty
        <Model> and added it to your <Model Library>. If
        the empty <Model> is needed, then create it and
        add it to the <Model Library>.

     A similar procedure would work if the empty <Model>'s
     instances were needed in the scope of an <Environment Root>
     rather than in other <Models>.

-------------------------------------------------------------------------------

Constraint Name: Non Overlapping DRM Class Summary Items

Definition:
 In a list of <DRM Class Summary Items>, no two shall have matching
 drm_class field values.

Rationale:
 A <DRM Class Summary Item> indicates the presence of instances of
 the given class in the context being summarized. Redundancy
 of this information does not add value, so it is forbidden in
 order to simplify consumption of such lists, and to minimize
 the size of the summary information.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Non Self Overlapping Perimeter Data Locations

Definition:
 The perimeter defined by a <Perimeter Data> instance shall
 not intersect with or overlap itself.

Rationale:
     None.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Octant Related Organizing Principle

Definition:
 For any octant-related organization instance OTRA, whether an
 instance of <Octant Related Geometry> or of <Octant Related Features>,

 1. The organization shall have a <Spatial Extent> component,
    defining the bounding volume that the octant is
    organizing into octants. Since a volume is being
    specified, this <Spatial Extent> shall be specified
    in terms of <Location 3D> instances.

 2. Each branch of OTRA shall comply with the following constraints.

    2.1 Each component representing an octant shall have a
        <Spatial Extent> component, specified in terms of
        <Location 3D> instances. In the case of octants represented
        by <Geometry Model Instance> or <Feature Model Instance>
        instances, the <Model> being referenced shall have the
        <Spatial Extent>.

    2.2 Each octant's <Spatial Extent> is distinct from that
        of all of its siblings, such that they do not overlap
        or intersect, except that they may have a common
        boundary.

    2.3 Consider the bounding volume defined by the <Spatial Extent>
        of OTRA, as divided into 8 octants of equal size in their
        native SRF.

 3. The strict_organizing_principle and unique_descendants field values
    of OTRA shall be SE_TRUE.

Rationale:
 1. The octant-related organization shall provide a <Spatial Extent>,
    so that the data provider specifies the bounding volume that the
    octant is dividing into octants.

 2. Each component representing an octant shall specify a <Spatial Extent>,
    because although octants are intended to be of equal size, "size"
    is not invariant under coordinate transformation. The <Spatial Extent>
    instances are necessary to ensure that the boundaries between octants
    are well-defined when coordinate conversions and transformations are
    applied.

 3. The <Spatial Extent> instances of the branches and
    the octants that they represent shall correspond.

 4. These <Spatial Extent> instances shall be 3D, because
    the concept of an octant is inherently 3D.

Example:
     None.

FAQs:
 Q. Why specify a <Spatial Extent> for each branch of an Octant? Aren't
    the octants of equal size?
 A. 'Size' is not invariant under coordinate transformation.

-------------------------------------------------------------------------------

Constraint Name: Parallelepiped Structure

Definition:
 For a <Parallelepiped Volume Extent> instance P, the following
 conditions shall hold.

 1. The <Reference Vector> components of P shall comply with the
    restrictions imposed in the specification of the
    <Parallelepiped Volume Extent> class.

 2. The relative orientations of the <Reference Vector> components
    of P shall specify a parallelepiped volume.

Rationale:
 A <Parallelepiped Volume Extent> instance shall comply with the
 definition of its class in order to specify a parallelepiped
 volume.

Example:
 1. No 2 <Reference Vector> components of a
    <Parallelepiped Volume Extent> instance may be parallel.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Perimeter Related Organizing Principle

Definition:
 1. For any perimeter-related organization,

    1.1 The regions defined by its branches shall not overlap; that is,
        the <Perimeter Data> on the branches shall define regions that
        do not overlap.

    1.2 For each branch of the organization, every primitive within
        that branch shall have a spatial extent overlapping that
        of the branch.

 2. Consider a perimeter-related organization PRA, which is either a
    <Perimeter Related Features> or a <Perimeter Related Geometry>.

    2.1 If PRA's strict_organizing_principle = SE_TRUE, then
        for each branch of PRA, each primitive within the branch
        shall have a spatial extent fully contained within that
        defined by the <Perimeter Data> corresponding to the
        branch.

        If PRA's strict_organizing_principle = SE_FALSE, then no guarantees
        exist as to how accurately the objects of the component tree
        rooted at PRA were placed into their "sorted bins" (the branches
        of PRA), apart from that specified by 1 (above).

    2.2 If PRA is a <Perimeter Related Features>, and the same
        <Feature Representation>
        instance belongs to more than one of its branches, then the
        unique_descendants and strict_organizing_principle flags of
        PRA shall be set to SE_FALSE.

    2.3 If PRA is a <Perimeter Related Geometry>, and the same
        <Geometry Representation>
        instance belongs to more than one of its branches, then the
        unique_descendants and strict_organizing_principle flags of
        PRA shall be set to SE_FALSE.

Rationale:
 1. In a hypothetical perimeter-related organization with overlapping
    <Perimeter Data>, determining which branch a given object belongs to
    would be ambiguous, so that the usefulness of the
    <Perimeter Related Organizing Principle> as a means of organizing
    primitives would be defeated.

 2. Each branch of a perimeter-related organization is intended
    to organize objects that fall within the specified perimeter for
    that branch.

 3. For perimeter-related organizations that interact with topology,
    the regions defined by the <Perimeter Data> are intended to fully
    partition the topological surface.

 4. The strict_organizing_principle flag of <Perimeter Related Features>
    and <Perimeter Related Geometry> was designed to allow the use
    of perimeter-related organization, even when a few primitives
    cross the boundaries of the organizing principle.

Example:
 1. Consider a <Perimeter Related Geometry> PRG with two branches,
    each with a distinct component <Union Of Primitive Geometry>
    as shown in the diagram below.

       <Perimeter Related Geometry>
           <>   "PRG"
           |
       -----------------------------------
       |                                 |
       |--- <Perimeter Data>             |--- <Perimeter Data>
       |     "PD1"                       |     "PD2"
       |                                 |
    <Union Of Primitive Geometry>   <Union Of Primitive Geometry>
          <>  "UPG1"                        "UPG2"
           |
       <Polygon>
          "A"

    By the <Perimeter Related Organizing Principle>, at least one
    of the vertices of A shall fall within the region described
    by the <Perimeter Data> PD1. If PRG has
    strict_organizing_principle == SE_TRUE, then ALL the vertices
    of A shall do so.

 2. Consider a second <Polygon> B, a sibling of A within UPG1.
    B falls on the boundary dividing the regions described by
    PD1 and PD2, such that at least one of B's vertices falls
    within PD1 and at least one of B's vertices falls PD2.

    By the <Perimeter Related Organizing Principle>, PRG's
    strict_organizing_principle flag shall be set to SE_FALSE,
    since branches are present which do not fully contain
    their objects.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Polygon As Bounded Plane

Definition:
 Consider a <Polygon> instance P having N ordered <Vertex> components
 v_i, where i is a member of { 1, 2, ..., N }. For each v_i, let L_i
 refer to the <Location> instance referenced by that <Vertex> as its
 <Location>. The following conditions shall hold.

 1. Each L_i shall specify unique spatial coordinates among
    L_k, where k is a member of { 1, 2, ..., N }.

 2. For each pair of line segments L_ij, L_rs, L_ij and L_rs
    shall not intersect unless i = s or j = r, in which case
    they shall intersect only at that common <Vertex>.

 3. The sequence of line segments L_ij shall specify a bounded
    portion of a plane.

 4. The concave flag of the polygon_flags field of P shall be
    set to SE_TRUE if P forms a concave polygon; otherwise
    the concave flag shall be set to SE_FALSE.

Rationale:
 This is the definition of a <Polygon>.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Polyhedron Structure

Definition:
 The collection of component <Polygons> of a <Polyhedron> must
 completely enclose a region of three-dimensional space.

Rationale:
 The geometric structure of a <Polyhedron> must be complete and
 consistent.

Example:
 1. A <Polyhedron> representing a cube would have six <Polygons> as
    components, one for each face of the cube.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Precedence of Property Set Index

Definition:
 <Geometry Representation> or <Feature Representation> instances
 may contain attribute and/or meta data
 objects and also <Property Set Index> instances that refer to <Property
 Sets>. If there is a clash between the attribute or meta data objects that
 are contained by the <Geometry Representation> or <Feature Representation>
 and any attribute or meta data
 objects that are contained by <Property Sets>, then objects contained
 directly by <Geometry Representation>s or <Feature Representation>s take
 precedence.

 <Geometry Representation>s and <Feature Representation>s may contain an
 ordered list of <Property Set Index> instances. If a <Geometry Representation>
 or <Feature Representation> contains references to more
 than one <Property Set> and there is a clash between the attribute objects
 they contain, then attribute objects contained in <Property Sets> referenced
 first in this ordered list have precedence over those contained in
 <Property Sets> that are referenced later.

 Precedence will behave differently depending on the multiplicity of the
 relationship that the attribute or meta data object in question has with
 the containing <Geometry Representation> or <Feature Representation>.
 In the event of a clash,
 the following rules will apply based on this enumeration.

 Zero or one:  The object contained directly by the <Geometry Representation> or
               <Feature Representation>
               is used. If the clash is between objects in <Property Sets>,
               then the object contained in the <Property Set> that is
               referenced earliest in the list of <Property Set Index>
               instances is used.

 Zero or more: Those contained directly by the <Geometry Representation> or
               <Feature Representation> are
               used, followed by those contained in the <Property Sets>, in
               the order that the <Property Sets> are referenced by the
               <Geometry Representation> or <Feature Representation>.

 Zero or more {ordered}: Those contained directly by the <Geometry Representation> or
               <Feature Representation> are used in order. Those contained in the
               <Property Set> referenced by the first <Property Set Index>
               instance in the list are then used, in order. Then those
               contained in the <Property Set> referenced by the second
               <Property Set Index> instance in the list, in order.

 And so on.

Rationale:
 Objects contained directly by <Geometry Representation> or
 <Feature Representation> instances are more closely related to the
 <Geometry Representation> or <Feature Representation> than those
 contained in a <Property Set> instance; they will be specific while
 those in a <Property Set> instance will be more generic.

 The order of the list of <Property Set Index> instances implies
 an order of precedence.

Example:
 1. A <Feature Representation> instance contains a <Data Quality> instance with
    fictional set to SE_TRUE. It also references a <Property Set> instance that
    contains a <Data Quality> instance with fictional set to SE_FALSE. As a
    <Feature Representation> instance may have only one <Data Quality> component,
    the <Data Quality> instance with fictional set to SE_TRUE is used, as it is
    contained directly by the <Feature Representation> instance.

 2. A <Geometry Representation> instance contains two <Property Table Reference>
    components and references a <Property Set> instance that contains another
    three. As a <Geometry Representation> instance may contain many
    <Property Table Reference> instances, all five are used by the
    <Geometry Representation> instance as required. The two that are contained
    directly are used first, then the three that are contained in the
    <Property Set> instance.

 3. Consider a <Geometry Representation> instance that contains two
    <Image Mapping Function> components and references a <Property Set>
    instance that contains another two. As a <Geometry Representation>
    instance may contain many ordered <Image Mapping Function> instances,
    all four are used by the <Geometry Representation> instance as required.
    The two that are contained directly are used in order first, then the
    three that are contained in the <Property Set> instance, again in order.

 4. Consider a <Geometry Representation> instance that contains two
    <Property Table Reference> components and references two <Property Set>
    instances. The first <Property Set> instance contains another
    <Property Table Reference> instance and the second <Property Set>
    instance contains another three <Property Table Reference> instances.
    As a <Geometry Representation> instance may contain many
    <Property Table Reference> instances, all six would be used by the
    <Geometry Representation> as required. The two that are contained directly
    would be used first, then that contained in the first <Property Set>
    instance, and finally the three that are contained in the second
    <Property Set> instance.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Primitive Summary Item Constraints

Definition:
 1. An instance of <Primitive Summary Item> shall have a drm_class field
    value corresponding to one of the following:
    - <Primitive Feature> or one of its subclasses
    - <Primitive Geometry> or one of its subclasses
    - classes that may legally appear in the component tree of a
      <Primitive Feature> or <Primitive Geometry>

 2. For any <Primitive Summary Item> instance B that is a component of
    another <Primitive Summary Item Instance> A, the drm_class represented
    by B shall be defined as a formal component of A, and the multiplicity
    of B shall comply with the corresponding component relationship between
    the two classes.

 3. For any <Primitive Summary Item> component S of an <Environment Root>
    instance ER, where the drm_class field corresponds to a class P, then
    the component tree of ER shall contain at least one instance of
    P, either in its <Feature Hierarchy>, its <Geometry Hierarchy>,
    or both, such that the component tree of the instance of P conforms
    with the pattern specified by S.

 4. For any <Primitive Summary Item> component S of an <Model> instance
    M, where the drm_class field corresponds to a class P, then the
    component tree of M shall contain at least one instance of
    P, either in its <Feature Model>'s <Feature Hierarchy>, its
    <Geometry Model>'s <Geometry Hierarchy>, or both, such that the
    component tree of the instance of P conforms with the pattern
    specified by S.

Rationale:
 A <Primitive Summary Item> represents an instance or group of instances
 of a primitive class, possibly together with part of its component tree,
 where the pattern thus described appears in the given scope. Consequently,
 the pattern thus described shall correspond to some valid set of
 relationships.

Example:
     None.

FAQs:
 Q. Can an "empty" <Model> have <Primitive Summary Item> components?
 A. No; such summary information indicates the presence of instances
    which by definition are *not* present in an "empty" <Model>.

-------------------------------------------------------------------------------

Constraint Name: Property Characteristic Restrictions

Definition:
 Consider a <Property Characteristic> instance C and a <Property> P
 such that C is a component of P.

 1. The characteristic_value.value_type of C shall correspond to
    the value type imposed by P. In the case where P is a
    <Property Description> instance, the value type of C shall
    be consistent with the restrictions imposed by the meaning of P.

 2. If C is not real valued, it shall not have either of the following
    as its meaning: EVC_SIGNIFICANT_DIGITS, EVC_TOLERANCE.

 3. Consider another, distinct <Property Characteristic> instance C2
    that is also a component of P.

    3.1 The meaning field values of C and C2 shall be distinct.

    3.2 If C specifies EVC_MINIMUM_VALUE and C2 specifies
        EVC_MAXIMUM_VALUE, the characteristic_value of C
        shall be less than or equal to that of C2.

Rationale:
 A <Property Characteristic> component of a <Property> qualifies the
 information in that <Property>, so it shall not conflict with the
 information already present in that <Property>. In the case of
 multiple <Property Characteristic> components for the same
 <Property>, they shall not conflict with one another.

Example:
 1. A <Table Property Description> instance T shall have at most one
    <Property Characteristic> specifying the EVC_MAXIMUM_VALUE for
    the set of <Data Table> cell elements corresponding to T.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Property Meaning Restrictions

Definition:
 For a <Property> instance P (that is, an instance of one of the concrete
 subclasses of <Property>), the following conditions shall hold.

 1. If P is an instance of <Property Value>, its value.value_type shall be
    consistent with the restrictions imposed by the meaning of P.

 2. If P is an instance of <Table Property Description>, its value_type
    and those of the corresponding elements of any applicable <Data Table>
    instances shall be consistent with the restrictions imposed by the
    meaning of P.

 3. If P specifies a real-valued EA or real-valued SE_Variable_Code M as
    its meaning, the value_unit of P shall specify a unit belonging to
    the EDCS Unit Equivalence Class to which M is bound.

 4. If P does not specify a real-valued EA as its meaning, the value_unit
    and value_scale of P shall be set to EUC_UNITLESS and ESC_UNI,
    respectively.

Rationale:
 The data type and unit of measure shall be semantically valid
 for the meaning of the <Property>.

Example:
 1. Consider a <Property Value> instance P specifying a numeric meaning,
    (in this example, EAC_WIDTH). To be semantically valid, the
    value_type of P shall be compatible with the abstract value type
    bound to EAC_WIDTH (REAL), and the value_unit shall be a member
    of EQC_LENGTH.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Property Set Components

Definition:
 A <Property Set> instance may contain attribute objects used by
 <Geometry Representation> and/or <Feature Representation> instances.
 If it contains attribute objects that are used by
 <Geometry Representation> instances and is referenced by a
 <Feature Representation> instance, the <Geometry Representation>-related
 attribute objects are ignored. The reverse is also true.

Rationale:
 This allows <Geometry Representation> and <Feature Representation>
 instances to use the same <Property Set> instance. This may be desirable
 if they share some of the same attribute objects; for example, if the
 <Geometry Representation> instances are actually alternate representations
 of the <Feature Representation> instances.

Example:
 1. A <Linear Feature> is associated with a <Union Of Primitive Geometry>
    that has been derived from it. Both reference the same <Property Set>
    that contains an <Inline Colour>, <Light Rendering Properties>, and
    <Browse Media>. The <Linear Feature> uses the <Inline Colour> and
    <Browse Media> instances, but ignores the <Light Rendering Properties>.
    The <Union Of Primitive Geometry> uses the <Inline Colour> and <Light
    Rendering Properties>, but ignores the <Browse Media>.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Property Set Table Size

Definition:
 For a given <Property Set Table Group> instance G with table_size = k,
 each <Property Set Table> component T of G shall have k
 <Property Set> components.

 For any given T within G, if regular = SE_TRUE, each of the k
 <Property Set> components of T shall contain the same number of
 SEDRIS objects, and these SEDRIS objects shall belong to the
 same classes. If regular = SE_FALSE for T, no such constraint
 holds.

 Note that G may have both regular and non-regular <Property Set Table>
 components, and that even if all <Property Set Table> components of G
 are regular, there is no constraint that they are all regular in the
 same way.

Rationale:
 This is a requirement in order to allow the <Property Set Table> components
 within a <Property Set Table Group> instance to be interchangeable.

Example:
 1. Consider a <Property Set Table Group> that contains three
    <Property Set Table> components: one for an Out-The-Window view,
    one for a RADAR view, and one for an Infra-Red view. All three
    <Property Set Table> instances contain 234 <Property Set>
    instances. Entry 234 in each <Property Set Table> contains
    a <Property Set> for the representation of "steel" in the
    three different domains.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Publishable Object

Definition:
 Note that where this constraint specifies that "instances"
 of an abstract class may be published, the instances of
 all concrete classes descended from that abstract class
 may be published.

 1. Instances of the following classes may be published.
           <Aggregate Feature>
           <Aggregate Geometry>
           <Colour Table Group>
           <Environment Root>
           <Feature Model>
           <Feature Topology>
           <Feature Topology Hierarchy>
           <Geometry Model>
           <Geometry Topology>
           <Geometry Topology Hierarchy>
           <Image>
           <Library>
           <Model>
           <Property Grid Hook Point>
           <Property Set Table Group>
           <Property Table>
           <Separating Plane Relations>
           <Sound>
           <Symbol>

 2. Instances of the following classes may be published,
    where they serve the role of link objects.

           <Base LOD Data>
           <Classification Data>
           <Hierarchy Data>
           <Oct Tree Data>
           <Quad Tree Data>
           <Perimeter Data>
           <Separating Plane Data>
           <Spatial Index Data>
           <State Data>
           <Time Constraints Data>

 3. An instance of a class not covered by 1 or 2 above
    shall not be published.

Rationale:
 1. <Environment Root> instances and instances of concrete
    subclasses of <Library> are desired for ITR.

 2. The SEDRIS objects organized by <Library> instances are
    desired for ITR.
    2.1 Within a <Data Table Library>, only
        <Property Table> instances may be referenced
        by <Property Table Reference> instances.

        <Mesh Face Table> instances are bound to
        specific <Finite Element Mesh> instances,
        and do not appear within a <Data Table Library>.

    2.2 The remaining classes for which instances are
        referenced within <Library> instances are
        <Property Set Table Group> - referenced by <Property Set Index>
        <Colour Table Group> - referenced by <Colour Index>
        <Feature Model> - referenced by <Feature Model Instance>
        <Geometry Model> - referenced by <Geometry Model Instance>
        <Image> - referenced by <Image Mapping Function>
        <Sound> - referenced by <Sound Instance>
        <Symbol> - referenced by <Label>

 3. <Feature Topology> and <Geometry Topology> instances are used
    to build topology hierarchies, and may be referenced in multiple
    places under cross-tile topology. When used in ITR, their link
    objects must also be published to form valid relationships.

 4. The various concrete subclasses under <Aggregate Feature>
    are desired for ITR, and are used to build feature hierarchies.
    When used in ITR, their link objects must also be published to
    form valid relationships. Similar reasoning holds for the
    subclasses of <Aggregate Geometry>, with the addition of
    <Separating Plane Relations> and <Separating Plane Data> for
    <Separating Plane Related Geometry>.

Example:
 1. Consider a <Model> A with a <Geometry Model> component GM_A
    in transmittal T_A, such that the data provider creating
    transmittal T_B wishes to create a <Geometry Model Instance>
    GMI_B in T_B that references GM_A.

    Since the <Geometry Model Instance> GMI_B will reside in
    transmittal T_B and GM_A is in T_A, an
    inter-transmittal reference (ITR) is needed to create the
    association from GMI_B to GM_A, so data provider B can
    create the relationship only if data provider A published
    <Geometry Model> GM_A. Since <Geometry Model> is on the
    list of classes for which instances may be published, the
    remainder of the issue is a matter for negotiation with
    data provider A to publish GM_A when creating transmittal
    T_A.

FAQs:
 Q. Why aren't <Union Of Features> and the other subclasses of
    <Aggregate Feature> on the list of classes for which
    instances may be published?

 A. Please re-read the constraint; instances of concrete classes
    descended from <Aggregate Feature> *are* permitted to be
    published.

 Q. Why isn't <Union Of Geometry Hierarchy> on the list of
    classes for which instances may be published?

 A. It *is* on the list of classes, since it is a subclass
    of <Union Of Geometry>, which in turn is a subclass of
    <Aggregate Geometry>.

-------------------------------------------------------------------------------

Constraint Name: Quadrant Related Organizing Principle

Definition:
 For any quadrant-related organization QTRA, whether a
 <Quadrant Related Features> or a <Quadrant Related Geometry>,

 1. QTRA shall have a <Spatial Extent>.

 2. Each branch of QTRA shall comply with the following constraints.

    2.1 Each component representing a quadrant shall have a
        <Spatial Extent> component. In the case of quadrants
        represented by <Geometry Model Instance> or
        <Feature Model Instance> instances, the <Model> being
        referenced shall have the <Spatial Extent>.

    2.2 The regions defined by the branches shall not overlap; that
        is, the <Spatial Extent> components of the component
        hierarchies shall not overlap.

    2.3 The four possible quadrant components' <Spatial Extent>
        instances shall be defined in their native SRF within the area
        specified by the QTRA's <Spatial Extent> as follows.
        (See HTML version of this document for accompanying diagram.)

        Consider the bounding area defined by the <Spatial Extent>
        of QTRA, as divided into 4 quadrants of equal size.

        2.3.1 If a branch with SE_QUADRANT_LEFT_FRONT is present,
              its <Spatial Extent> shall specify the area of the
              northwest quadrant, such that

              2.3.1.1 its eastern boundary aligns with the western
                      boundary of the SE_QUADRANT_RIGHT_FRONT quadrant's
                      <Spatial Extent>, if present, and

              2.3.1.2 its southern boundary aligns with the northern
                      boundary of the SE_QUADRANT_LEFT_BACK quadrant's
                      <Spatial Extent>, if present.

        2.3.2 If a branch with SE_QUADRANT_RIGHT_FRONT is present,
              its <Spatial Extent> shall specify the area of the
              northeast quadrant, such that

              2.3.2.1 the <Location> instance representing its
                      northeast corner corresponds to that of
                      QTRA's <Spatial Extent>,

              2.3.2.2 its western boundary aligns with the eastern
                      boundary of the SE_QUADRANT_LEFT_FRONT quadrant's
                      <Spatial Extent>, if present, and

              2.3.2.3 its southern boundary aligns with the northern
                      boundary of the SE_QUADRANT_RIGHT_BACK quadrant's
                      <Spatial Extent>, if present.

        2.3.3 If a branch with SE_QUADRANT_LEFT_BACK is present,
              its <Spatial Extent> shall specify the area of the
              southwest quadrant, such that

              2.3.2.1 the <Location> instance representing its
                      southwest corner corresponds to that of
                      QTRA's <Spatial Extent>,

              2.3.3.2 its eastern boundary aligns with the western
                      boundary of the SE_QUADRANT_RIGHT_BACK quadrant's
                      <Spatial Extent>, if present, and

              2.3.3.3 its northern boundary aligns with the southern
                      boundary of the SE_QUADRANT_LEFT_FRONT quadrant's
                      <Spatial Extent>, if present.

        2.3.4 If a branch with SE_QUADRANT_RIGHT_BACK is present,
              its <Spatial Extent> shall specify the area of the
              southeast quadrant, such that

              2.3.4.1 its western boundary aligns with the eastern
                      boundary of the SE_QUADRANT_LEFT_BACK quadrant's
                      <Spatial Extent>, if present, and

              2.3.4.2 its northern boundary aligns with the southern
                      boundary of the SE_QUADRANT_RIGHT_FRONT quadrant's
                      <Spatial Extent>, if present.

 3. The strict_organizing_principle and unique_descendants field values
    of QTRA shall be SE_TRUE.

Rationale:
 1. The quadrant-related organization shall provide a <Spatial Extent>,
    so that the data provider specifies the bounding area that the
    quadtree is dividing into quadrants.

 2. Each component representing a quadrant shall specify a <Spatial Extent>,
    because although quadrants are intended to be of equal size, "size"
    is not invariant under coordinate transformation. The <Spatial Extent>
    instances are necessary to ensure that the boundaries between quadrants
    are well-defined when coordinate conversions and transformations are
    applied.

 3. The <Spatial Extent> instances of the branches and
    the quadrants that they represent shall correspond.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Reference To Data Table Library

Definition:
 The following conditions apply to instances of
 <Property Table Reference>.

 1. The <Property Table> instance specified by the
    <Property Table Reference> instance shall be a
    component of a <Data Table Library> instance.

 2. The <Property Table> instance shall contain an <Axis>, the axis_type
    of which corresponds to that specified by the <Property Table Reference>.

 3. The <Axis> instance thus specified shall have axis_value_count
    greater than or equal to (index_on_axis + 1), where
    index_on_axis is that specified by the <Property Table Reference>
    instance.

Rationale:
 By definition, a <Property Table Reference> specifies an N-1 dimensional
 "slice" of an N dimensional <Property Table> in a <Data Table Library>.

 To define that slice, the <Axis> and "tick mark" value specified by
 the <Property Table Reference> shall correspond to part of the
 <Property Table> being referenced.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Required Reference Vector Location

Definition:
  Given any object that has a <Location> component, that <Location> (or
  the first <Location> in an ordered list of <Location> components)
  becomes the (default) <Location> in the context for the aggregation
  tree stemming from that object.

  A <Reference Vector> is required to have a <Location> component whenever
  the <Reference Vector> is a component of a <Polygon>, <Line>, <Infinite
  Light>, <Moving Light Behaviour>, or <Union Of Geometry>.

Rationale:
 The SEDRIS API requires an appropriate <Location> to convert a
 <Reference Vector> to or from non-vector spatial reference frames, such as
 Geodetic.  For most <Reference Vector> aggregators, the <Location> is
 supplied by the context inheritance mechanism.  For the remaining classes
 covered by this rule, inheritance cannot be relied on to supply an
 appropriate <Location> component.

 Inheritance allows <Reference Vector> and <World 3x3> instances to
 automatically inherit a <Location> component as required for some
 coordinate transformations and conversions.

Example:
 1. A large <Polygon> with a <Reference Vector> component might use the
    "centre" of the <Polygon> for the <Reference Vector>'s <Location>
    component.

 2.  A <Line> with a <Reference Vector> component might use the <Location>
     of one of its <Vertex> components for the <Reference Vector>'s
     <Location> component.

 3. An <Infinite Light> is shining down on the local area.  The "down"
    direction <Reference Vector> component shall have a localizing <Location>
    component, since parallel translations of a "down" vector will not point
    down over most places on the Earth's (curved) surface.

 4. A <Positional Light> has both a <Location> component and a <Lobe Data>
    component. The <Lobe Data>, in turn, has 2 <Reference Vector> components.
    These two <Reference Vector> instances inherit the <Positional Light>
    instance's <Location> component by this rule.

FAQs:
 Q. How does choice of Location component affect <Reference Vector>
    instances in <Model> instances that have been specified in
    LSR spatial reference frames?
 A. In the case of <Model> instances that use LSR, the choice has no effect
    at all. The LSR origin (0, 0, 0), for example, could always be used.
    However, if the <Model> is instanced in the context of an
    <Environment Root> or another <Model> instance, the SRF of which has
    a curvilinear coordinate system such as Geodetic, the effect may be
    noticeable with a large <Model> instance.

    For example, if two <Reference Vector> instances in the <Model> are
    both pointing "up" and use the same <Location>, when the <Model> is
    instanced they will remain parallel but may no longer be pointing up.
    If, on the other hand, they each have a different <Location>, they
    each will point up at the corresponding instance <Location>, but
    they will no longer be parallel due to the curvature of the Earth.

 Q. How does the data consumer use this form of inheritance?
 A. The data consumer does not use it directly. It is sometimes used by the
    Read (Extraction) API implementation when the consumer requests data
    extraction in another spatial reference frame.

-------------------------------------------------------------------------------

Constraint Name: Separating Plane Related Organizing Principle

Definition:
 1. The <Location 3D> components of a <Separating Plane> shall
    specify a plane.

 2. For any <Separating Plane Related Geometry> instance S,
    2.1 No two <Separating Plane Relations> components of S
        shall specify coplanar <Separating Plane> instances.

    2.2 For each component <Separating Plane Relations> R of S,

        2.2.1 Every primitive within each branch of R shall
              have a spatial extent overlapping that of the
              half-space specified by the branch.

        2.2.2 If S's strict_organizing_principle = SE_TRUE,
              every primitive within each branch of R shall
              have a spatial extent fully contained within the
              half-space specified by the <Separating Plane Data>
              corresponding to the branch. If S's
              strict_organizing_principle = SE_FALSE, then no
              guarantees exist as to how accurately the objects
              of the component tree rooted at S were placed into
              their sorted "bins", apart from that specified by
              2.2.1

Rationale:
 A <Separating Plane> exists to specify a plane.

 The purpose of a <Separating Plane Related Geometry> is to
 organize geometry instances based on their relationships
 with the specified set of <Separating Plane> instances.
 For this purpose to be fulfilled, each primitive shall at
 least overlap the half-space "bin" into which it is placed
 by the organization, and if the organizing principle is
 strictly followed, it shall be entirely contained within
 that "bin".

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Spatial Index Related Organizing Principle

Definition:
 1. For any spatial-index-related organization SIRO,

    1.1 The column_width of SIRO shall be a positive number.

    1.2 The row_width of SIRO shall be a positive number.

    1.3 For each branch of the organization, the corresponding
        <Spatial Index Data> shall define a region in the
        spatial index, such that

        1.3.1 The column_index of the <Spatial Index Data>
              instance shall be between 1 and the column_count
              defined by SIRO.

        1.3.2 The row_index of the <Spatial Index Data>
              instance shall be between 1 and the row_count
              defined by SIRO.

        1.3.3 Each primitive within the branch shall have a
              spatial extent overlapping that defined by the
              <Spatial Index Data> of the branch.

 2. Consider an instance SRA, which is either a
    <Spatial Index Related Features> or a
    <Spatial Index Related Geometry>.

    2.1 If SRA's strict_organizing_principle = SE_TRUE, then
        for each branch of SRA, each primitive within the branch
        shall have a spatial extent fully contained within that
        defined by the <Spatial Index Data> corresponding to the
        branch. (If SRA's strict_organizing_principle = SE_FALSE,
        then no guarantees exist as to how accurately the instances
        of the component tree rooted at SRA were placed into their
        "sorted bins" (the branches of SRA), apart from that
        specified by 1.)

    2.2 If SRA is a <Spatial Index Related Features>, and the same
        <Feature> instance belongs to more than one of its branches, then
        the unique_descendants and strict_organizing_principle flags of
        SRA shall be set to SE_FALSE.

    2.3 If SRA is a <Spatial Index Related Geometry>, and the same
        <Geometry Representation> instance belongs to more than one of
        its branches, then the unique_descendants and
        strict_organizing_principle flags of SRA shall be set to SE_FALSE.

Rationale:
 1. Each branch of a spatial-index-related organization is intended
    to organize instances that fall within the specified spatial-index for
    that branch.

 2. The strict_organizing_principle flag of <Spatial Index Related Features>
    and <Spatial Index Related Geometry> was designed to allow the use
    of spatial-index-related organization, even when a few primitives
    cross the boundaries of the organizing principle.

Example:
 1. Consider a <Spatial Index Related Geometry> instance with row_count = 1,
    column_count = 4, row_width = 1000 metres, column_width = 1000 metres.
    For simplicity, each of the 4 branches of the <Spatial Index Related
    Geometry> in this example is a <Union Of Primitive Geometry>.

                     <Spatial Index Related Geometry>
                                    <>
                                    |------- <AUTM Location 3D>
                                    |         (0, 0, 0)
                                    |
     -------------------------------------------------------------
     |                     |                  |                  |
     |                     |                  |                  |
     |- <Spatial Index     |- <Spatial Index  |- <Spatial Index  |- <Spatial
     |   Data>             |   Data>          |   Data>          |Index Data>
     |   (index = 1)       |   (index = 2)    |   (index = 3)    |(index = 4)
     |                     |                  |                  |
     |                     |                  |                  |
    <Union Of          <Union Of          <Union Of          <Union Of
    Primitive          Primitive           Primitive         Primitive
    Geometry>          Geometry>           Geometry>         Geometry>


    Since the origin of the collection (its lower-left corner, the
    <AUTM Location 3D> is (0, 0, 0), the coverages of the branches are:
    1) from (0, 0)    to (1000, 1000)
    2) from (1000, 0) to (2000, 1000)
    3) from (2000, 0) to (3000, 1000)
    4) from (3000, 0) to (4000, 1000)

    (Note that a <Spatial Index Related Geometry> does not specify the
    range of z/height/elevation values.)

    Consider a triangular <Polygon> in branch #2 of this aggregation,
    with <Vertex> <Location> instances (1995, 0, 0), (2005, 0, 0)
    (2005, 10, 0).

    Since this <Polygon> crosses the boundary between branch #2 and
    branch #3, this <Spatial Index Related Geometry>'s
    strict_organizing_principle shall be set to SE_FALSE.

 2. Consider a <Spatial Index Related Features> with row_count = 1,
    column_count = 4, row_width = 1000 metres, column_width = 500 metres.
    For simplicity, each of the 4 branches of the <Spatial Index Related
    Features> instance in this example is a <Union Of Features> instance.

                     <Spatial Index Related Features>
                                    <>
                                    |------- <AUTM Location 3D>
                                    |         (0, 0, 0)
                                    |
     -----------------------------------------------------------
     |                    |                 |                  |
     |                    |                 |                  |
     |- <Spatial Index    |- <Spatial Index |- <Spatial Index  |-<Spatial
     |   Data>            |   Data>         |   Data>          |  Index Data>
     |   (index = 1)      |   (index = 2)   |   (index = 3)    | (index = 4)
     |                    |                 |                  |
     |                    |                 |                  |
    <Union Of          <Union Of          <Union Of          <Union Of
    Features>          Features>           Features>         Features>


    Since the origin of the collection (its lower-left corner, the
    <AUTM Location 3D> is (0, 0, 0), the coverages of the branches are:
    1) from (0, 0)    to (500, 1000)
    2) from (500, 0)  to (1000, 1000)
    3) from (1000, 0) to (1500, 1000)
    4) from (1500, 0) to (2000, 1000)

    (Note that a <Spatial Index Related Features> does not specify the
    range of z/height/elevation values.)

    Consider a triangular <Areal Feature> in branch #2 of this aggregation,
    consisting of one regular <Feature Face>, which in turn has an external
    <Feature Face Ring> containing 3 <Feature Edge> instances as follows:

                         <Feature Face Ring>
                                 <>
         -----------------------------------------------
         |                      |                      |
         | <Edge Direction>     | <Edge Direction>     | <Edge Direction>
         | (forwards = SE_TRUE) | (forwards = SE_TRUE) | (forwards = SE_TRUE)
         |                      |                      |
    <Feature Edge>         <Feature Edge>         <Feature Edge>
    (from A to B)          (from B to C)          (from C to D)

    where A, B, C are <Feature Nodes> such that
    A's <Location> is (995, 0)
    B's <Location> is (1005, 0)
    C's <Location> is (1005, 20)

    Since the <Areal Feature> thus crosses the boundary between branch #2 and
    branch #3, the <Spatial Index Related Features>'
    strict_organizing_principle shall be set to SE_FALSE.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: State Related Organizing Principle

Definition:
 For any state-related aggregation SRA, whether a <State Related Features>
 or a <State Related Geometry>,

 1. The state_tag of SRA shall be "state-applicable".

 2. Each branch of SRA shall comply with the following constraints.

    2.1 The <State Data> associated with that branch shall have a
        state_value, the value_type of which matches that of SRA's
        active_state_value.

    2.2 The <State Data> associated with that branch shall have a
        state_value which does not overlap with that of any other
        branch's <State Data> within SRA.

 3. If SRA has a <State Control Link> instance as a component, then
    the return type of each of the <Expression> components of the
    <State Control Link> shall match that of SRA's active_state_value's
    value_type.

Rationale:
 1. The state_tag shall specify some EAC that is actually legal for
    use as a state.

 2. The active_state_value, and each of the possible <State Data>
    instances' state_values, as well as the return types of the
    <State Control Link> instance's <Expression> components (if any)
    are all designed to be interchangeable, since any one of them
    could determine the active state of SRA at some point.

 3. The values specified by the <State Data> instances may not overlap,
    because the active_state_value shall unambiguously specify which
    state that SRA is in.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Time Dependency

Definition:
 <Relative Time>, <Absolute Time Interval>, and
 <Relative Time Interval> instances may each have a component
 <Absolute Time> instance, and the restrictions on their
 field values depend on the value of the <Absolute Time>
 component, when it is present.

 1. If an <Absolute Time> is present with a
    time_value.time_configuration entry specifying that the day
    field value is not applicable,
    1.1 for <Absolute Time Interval> and <Relative Time>,
        delta_days = 0.
    1.2 for <Relative Time Interval>,
        delta_start_days = delta_stop_days = 0.

 2. For <Absolute Time Interval> and <Relative Time>,
    if an <Absolute Time> is specified for which
    month is not applicable but day is applicable,
    delta_days shall be in the range
    (1 - day) to (30 - day)
    where day is the <Absolute Time>'s day field.

 3. For <Absolute Time Interval> and <Relative Time>,
    if month and year are not applicable, then
    day shall be in the range [0, 365] inclusive.

 4. If no <Absolute Time> component is present, or restrictions 1-3
    do not apply, then delta_days has no constraints for
    <<Time Dependency>>.

Rationale:
 1. No meaningful delta values can be applied to the day value of an
    <Absolute Time> for the case where a day value is not
    specified by that <Absolute Time>'s SE_Time_Configuration.

 2. A <Time Interval> that is referenced to an <Absolute Time>
    for which no specific month is specified is assumed to have a
    30 day month, and the interval cannot exceed a 30 day period.

 3. When using day of year (rather than explicitly specifying the month)
    for an unspecified year, the year is assumed to be a 365-day year.

 4. Part 4 of this constraint only applies to the cases explicitly
    specified by the constraint.

 5. If the day of the year is specified rather than a specific month, then
    the day shall fall within the bounds of a 365-day year (negative days
    in a year are not defined).

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Time Interval Calculation

Definition:
 A <Time Interval> instance that is referenced to an <Absolute Time>
 that does not specify a month is treated as having a 30 day month, such
 that its fields shall specify an interval not exceeding a 30 day period.
 See <Time Dependency> constraint, part 2.

 A <Time Interval> instance that is referenced to an <Absolute Time>
 that does specify a month shall be calculated using the actual number of
 days in that month.

Rationale:
     None.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Union Organizing Principle

Definition:
 1. For a <Union Of Primitive Geometry> instance U, the
    strict_organizing_principle and unique_descendants field values shall be
    SE_TRUE, and all U's <Primitive Geometry> components shall be distinct.

 2. For a <Union Of Feature Topology> instance U, all U's
    <Feature Topology> components shall be distinct.

 3. For a <Union Of Geometry Topology> instance U, all U's
    <Geometry Topology> components shall be distinct.

 4. For a <Union Of Geometry Hierarchy> instance U, all U's
    <Geometry Hierarchy> components shall be distinct. Furthermore, no
    two <Geometry Hierarchy> components of U shall organize exactly the
    same collection of geometric data.

Rationale:
 1. All members of a union shall be distinct to avoid
    semantic ambiguity.

 2. In the case of 2 <Union Of Geometry Hierarchy> components
    attempting to provide alternate representations of the
    same underlying data, the appropriate representation
    mechanism is <Alternate Hierarchy Related Geometry>.

Example:
 1. Consider a <Union Of Geometry Hierarchy> instance for
    which the ordering_reason is semantically significant.
    The same <Geometry Hierarchy> instance cannot appear
    twice in the union, because the semantic meaning of
    that instance would be ambiguous.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Variable Meaning Restrictions

Definition:
 For a <Variable> instance V, the following conditions shall hold.

 1. The value_type of V shall be consistent with the restrictions
    imposed by V's meaning.

 2. If V specifies a real-valued EA or real-valued SE_Variable_Code
    M as its meaning, the value_unit of V shall specify a unit
    belonging to the EDCS Unit Equivalence Class to which M is bound.

 3. If V does not specify a real-valued EA or real-valued
    SE_Variable_Code as its meaning, the value_unit and value_scale
    of V shall be set to EUC_UNITLESS and ESC_UNI, respectively.

Rationale:
 A <Variable> instance shall specify valid and consistent unit
 and data type information.

Example:
     None.

FAQs:
     None.

-------------------------------------------------------------------------------

Constraint Name: Volume Shell Face Consistency

Definition:
 The following restrictions apply:
 A <Feature Face> instance shall appear no more than twice in a
 <Feature Volume Shell>, once with each <Face Direction>.

Rationale:
 Since a <Feature Face> has exactly two sides, it can associated with
 at most two <Feature Volume Shell> instances, and can appear at most
 twice in the collection of <Feature Face> instances associated with a
 single <Feature Volume Shell>.

Example:
 1. A <Feature Volume> instance V1 representing a cube is bounded
    by six <Feature Face> instances F1 through F6.  F1, F2, F3,
    F4, F5, and F6 are all associated to V1.  F1, F2, F3, F4, F5,
    and F6 each appear once in the collection of <Feature Face>
    instances associated with the exterior <Feature Volume Shell>
    of V1.

FAQs:
 Q. Can a <Feature Face> instance be associated with a
    <Feature Volume Shell> more than once?
 A. Yes.  A "dangling" <Feature Face> that projects into the
    interior of a <Feature Volume> is included in the
    external shell of that <Feature Volume> two times, once
    for each side of the <Feature Face>.