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

Constraint Name: Attribute Set Components

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

Rationale:
 This allows <Geometry> and <Feature> instances to use the same
 <Attribute Set>. This may be desirable if they share some of the
 same attribute objects; for example, if the <Geometry> is actually
 an alternate representation of the <Feature>.

Example:
 1. A <Linear Feature> is associated with a <Union Of Primitive Geometry>
    that has been derived from it. Both reference the same <Attribute 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: Attribute Set Table Size

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

 For any given T within G, if regular = SE_TRUE, each of the k
 <Attribute 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 <Attribute Set Table>
 components, and that even if all <Attribute 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 <Attribute Set Table> instances
 within an <Attribute Set Table Group> to be interchangeable.

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

FAQs:
     None.

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

Constraint Name: Axis Type Restrictions

Definition:
 The following restrictions apply.

 1. In <Regular Axis>, <Irregular Axis> and <Interval Axis>
    instances,

    1.1 The axis_type shall correspond to a numeric attribute.

        1.1.1 If the axis_type is specified by an EDCS_Attribute_Code,
              it shall correspond to an EDCS Attribute (EA)
              bound to a numeric value type.

        1.1.2 If the axis_type is specified by an SE_Variable_Code,
              it shall represent a variable bound to a numeric
              value type.

    1.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.

    1.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.

 2. In an <Enumeration Axis> instance X,

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

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

 3. In an <Interval Axis> instance X,

    3.1 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.

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

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

 4. In an <Irregular Axis> instance X,

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

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

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

 5. In an instance of <Regular Axis>, 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.

 6. In regard to spatial <Axis> instances,

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

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

        6.1.2 For x, y coordinates,
              EAC_SPATIAL_LINEAR_PRIMARY_COORDINATE
              EAC_SPATIAL_LINEAR_SECONDARY_COORDINATE

        6.1.3 For z and elevation coordinates,
              EAC_SPATIAL_LINEAR_TERTIARY_COORDINATE

    6.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.

    6.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: Colour Mapping Restrictions

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

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

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

 4. The SE_CLR_MAPNG_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 SE_CLR_MAPNG_LGT_RENDER_BHVR_PRIMARY and
 SE_CLR_MAPNG_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> with 2 <Inline Colours> and an <Image Mapping
    Function>, where the <Image Mapping Function>'s method is set to
    SE_IMG_MAPNG_METH_BLEND.
        Each <Inline Colour> shall specify whether it is primary, image
    blend, or neither, and which side of the <Polygon> 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 (e.g., 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 have a <Connected Feature Edge> which associates
         to that <Feature Edge>.

    1.2. For each <Feature Edge> that has FN as an ending node,
         FN shall have a <Connected Feature Edge> which associates
         to that <Feature Edge>.

    1.3. If FN is neither a starting nor an ending node of a given
         <Feature Edge>, that <Feature Edge> shall not appear
         among the associates of any of FN's <Connected Feature Edge>
         components.

    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's <Connected Feature Edge> components
         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
    <Connected Geometry Edge> components, if any exist.

    2.1. For each <Geometry Edge> that has GN as a starting node,
         GN shall have a <Connected Geometry Edge> which associates
         to that <Geometry Edge>.

    2.2. For each <Geometry Edge> that has GN as an ending node,
         GN shall have a <Connected Geometry Edge> which associates
         to that <Geometry Edge>.

    2.3. If GN is neither a starting nor an ending node of a given
         <Geometry Edge>, that <Geometry Edge> shall not appear
         among the associates of any of GN's <Connected Geometry Edge>
         components.

    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's <Connected Geometry Edge> components
         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,

         - twice, if GE is a loop.

Rationale:
 <Connected Feature Edge> is the one-directional topological relationship
 connecting a <Feature Node> to the ordered set of ordered collection(s) of
 <Feature Edge> instances that have it as an endpoint. If there are no such
 <Feature Edge> instances, then there shall be no <Connected Feature Edge>
 on that <Feature Node>.

 <Connected Geometry Edge> is the one-directional topological relationship
 connecting a <Geometry Node> to the ordered set of ordered collection(s) of
 <Geometry Edge> instances that have it as an endpoint. If there are no such
 <Geometry Edge> instances, then there shall be no <Connected Geometry Edge>
 on that <Geometry Node>.

Example:
 1. Consider a <Feature Edge> A that has distinct starting and ending
    <Feature Node> instances X1 and X2.

    X1 shall have at least one <Connected Feature Edge> component,
    which associates to A, and X2 shall have at least one
    <Connected Feature Edge> component, which associates to A.

 2. Consider <Geometry Node> Y that is not the endpoint of any <Geometry
    Edge>. If Y is mistakenly created with a <Connected Geometry Edge>,
    then Y is invalid, since the <Connected Geometry Edge> implies that Y
    *does* belong to some <Geometry Edge>.

FAQs:
 Q. For a loop edge (that is, an edge wherein the same node appears
    as both the starting and ending node), how many times does the
    edge appear in that node's <Connected Feature Edge> /
    <Connected Geometry Edge> lists?
 A. Twice. Non-loop edges would appear only once.

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

Constraint Name: Contained Node Restrictions

Definition:
 1. A <Feature Face> FF has the following relationship with its associated
    <Feature Node> instances, if any exist.

    1.1. At any feature topology level, if FF is associated with any
         <Feature Node> instance FN, then

         1.1.1 If FF has an <External Feature Face Ring>,
               FN shall lie within the boundary of that ring.

         1.1.2 For each <Internal Feature Face Ring> of FF, FN
               shall not lie within the boundary of that ring.

    1.2. At feature topology levels 3 and 4, FF shall be associated to
         each <Feature Node> that is contained within its boundary.

    1.3. If FF contains no <Feature Node> instance within its boundaries,
         FF shall have no associated <Feature Node> instances.

    1.4. If a <Feature Node> FN does not lie within the boundary of any
         <Feature Face>, FN shall have no associated <Feature Face>
         instances.

 2. A <Geometry Face> GF has the following relationship with its associated
    <Geometry Node> instances, if any exist.

    2.1. At any geometry topology level, if GF is associated with a
         <Geometry Node> GN, GN shall lie within the boundary of
         GF's <Geometry Face Ring>.

    2.2. At geometry topology levels 3 and 4, GF shall be associated to
         each <Geometry Node> that is contained within its boundary.

    2.3. If GF contains no <Geometry Node> instances within its boundaries,
         GF shall have no associated <Geometry Node> instances.

    2.4. If a <Geometry Node> GN does not lie within the boundary of any
         <Geometry Face>, GN shall have no associated <Geometry Face>
         instances.

Rationale:
 The association between <Feature Node> and <Feature Face> is the
 topological relationship between a <Feature Face> and a <Feature Node>
 that is contained within its boundaries, so by definition, if the
 <Feature Face> has an external boundary, the <Feature Node> shall
 lie within that boundary. The rationale for the relationship between
 <Geometry Node> and <Geometry Face> is the same.

 Unlike <Geometry Face> instances, a <Feature Face> instance may have
 inner boundaries, indicating "holes" in the <Feature Face>. Consequently,
 a <Feature Node> shall be contained within a <Feature Face> but not
 fall into one of the "holes" if it is to be considered "contained"
 within that <Feature Face>.

Example:
 1. Consider a <Feature Face> X that contains a <Feature Node> A, where X is
    part of the <Topology Hierarchy> of a <Classification Related Features>
    with SE_FEAT_TOPO_LVL_FOUR. X shall have an association with A in order
    to be valid.

 2. Consider <Feature Face> Y that does not contain any <Feature Node>
    instances. If Y is mistakenly created with an association to some
    <Feature Node>, then Y is invalid since the association implies
    that Y *does* contain the <Feature Node>.

FAQs:
 Q. Consider a <Feature Face> with a <Feature Face Ring> FFR. Should the
    <Feature Node> instances forming the endpoints of the edges of FFR
    be associated to the <Feature Face>?

 A. No, they should not. The containment relationship expressed by
    that association is one of "proper" containment; that is, it does
    not include <Feature Node> instances that lie on the boundary of
    the <Feature Face>.

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

Constraint Name: Continuous LOD Restrictions

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

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

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

 2. <Continuous Level Of Detail Related Geometry> always represents
    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 Link Objects

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

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

 3. 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>.

   For model instances, the indices into the <Interface Template> 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 Level Of Detail 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.

    1.1 If a <Feature Edge> FE associates to a <Feature Face> FF, then
        FE shall be part of one of the <Feature Face Ring> components
        of FF.

    1.2 At feature topology level 3 or higher, if a <Feature Edge> FE
        is part of any <Feature Face Ring> of a <Feature Face> FF, then
        FE shall have an association to FF. At lower levels of topology,
        this relationship may be present, but it is not required.

 2. <Geometry Edge> instances have the following relationship with
    <Geometry Face> instances.

    2.1 If a <Geometry Edge> GE associates to a <Geometry Face> GF, then
        GE shall be part of one of the <Geometry Face Ring> components
        of GF.

    2.2 At geometry topology level 3 or higher, if a <Geometry Edge> GE
        is part of any <Geometry Face Ring> of a <Geometry Face> GF, then
        GE shall have an association to GF. At lower levels of topology,
        this relationship may be present, but it is not required.

Rationale:
 <External Feature Face Ring> is the one-directional topological relationship
 between a <Regular Feature Face> and the ordered collection of <Feature
 Edges> that form its outer boundary, so by definition, a <Feature Edge>
 that belongs to an <External Feature Face Ring> shall border some
 <Feature Face>.

 <Geometry Face Ring> is the one-directional topological relationship
 between a <Geometry Face> and the ordered collection of <Geometry Edges>
 that form its outer boundary, so by definition, a <Geometry Edge> that
 belongs to a <Geometry Face Ring> shall border some <Geometry Face>.

 <Internal Feature Face Ring> is the one-directional topological relationship
 between a <Feature Face> and the ordered collection of <Feature Edges> that
 form one of its inner boundaries, so by definition, a <Feature Edge> that
 belongs to an <Internal Feature Face Ring> shall border some <Feature Face>.

Example:
 1. A <Feature Edge> X is associated with <Feature Faces> A and B. By
    the <Edges Bordering Faces> rule, X shall belong to
    a <Feature Face Ring> of A and a <Feature Face Ring> of B.

 2. A <Geometry Face> GF has a <Geometry Face Ring> containing
    <Geometry Edge> GE, at geometry topology level 0. GE is
    NOT required to associate to GF, although it is allowed to do so.

FAQs:
 Q. If a given context within a transmittal contains <Feature Topology>
    but has feature topology level less than 3, can that context
    legally contain <Feature Edges> that associate to their
    <Feature Faces>? What about <Geometry Topology>?
 A. Yes, topology of less than level 3 may contain such associations,
    provided they comply with <Edges Bordering Faces>; they're just
    not *required* for topology levels less than 3. This applies to
    both geometry and feature topology.

 Q. I, as a consumer, have encountered a <Feature Edge> with an
    association to a <Feature Face>. Is the <Feature Edge> guaranteed
    to provide a comprehensive list of all the <Feature Faces>
    that use the <Feature Edge>? What about <Geometry Topology>?
 A. If the <Feature Edge> appears in a context with feature_topology_level
    of 3 or more, then the list of associated <Feature Edges> is
    guaranteed to be comprehensive. For lower-level topology, the
    list is required only to comply with <Edges Bordering Faces>,
    and is not guaranteed to be comprehensive. This also applies
    on the <Geometry Topology> side.

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

Constraint Name: Elaboration Of Classification Data

Definition:
 For a <Property Value> component of a <Classification Data>,
 <Environmental Domain Summary>, <Reference Surface>, or
 <Table Property Description>, the meaning field of the
 <Property Value> shall specify an EAC that is designated
 as "classification-applicable".

Rationale:
 Some ECCs require other elaboration by EACs, so each class
 containing an EDCS_Classification_Code field has optional
 <Property Value> components, which are provided so that
 such elaboration can be expressed.

 These <Property Value> components cannot be attached to the aggregate
 of the <Classification Data>, because
 1. A <Property Value> applies directly to the object of which it is
    a component, so that a <Property Value> of the <Classification Data>'s
    aggregate applies directly to the aggregate, rather than the
    <Classification Data> itself.

 2. In the cases of <Environmental Domain Summary>,
    <Table Property Description>, and <Classification Data> in the
    role of link object, the <Property Value> instances could not be
    constrained to apply only to the desired ECC, and would
    make it impossible to have, respectively

    - more than one <Environmental Domain Summary> on a
      <Transmittal Summary>

    - <Data Table> instances with more than one data element of any given
      type of index to another <Data Table>

    - classification-related aggregations with links using
      elaborated <Classification Data>

Example:
 1. A <Point Feature> classified (via a <Classification Data>) as
    ECC_BUILDING often requires a <Property Value> for
    EAC_BUILDING_FUNCTION to better classify the <Point Feature>.

FAQs:
     None.

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

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> 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 (e.g., an
 <Environment Root>, <Image Anchor>). A <Location> in another spatial
 reference frame (e.g. geomagnetic when the reference frame is geodetic)
 is therefore undefined.

Example:
 1. If a <Environment Root>'s spatial reference frame is AUTM, no <Locations>
    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 Grids>, an <Image Anchor>
    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> within a <Feature Face Ring>,
    and for each consecutive <Geometry Edge> within a
    <Geometry Face Ring>, the <Edge Direction> shall be consistent
    with the starting and ending nodes of the edge.

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

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

Rationale:
 Replicated information shall be consistent.

Example:
     None.

FAQs:
     None.

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

Constraint Name: Feature Edge Restrictions

Definition:
 The following restrictions apply.

 1. The <Location> instances within a <Feature Edge> shall be distinct
    (i.e., no 2 may have the same coordinates).

 2. <Feature Edges> may meet only at <Feature Nodes>, and <Feature Faces>
    may meet only along one or more <Feature Edges>.

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

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

Rationale:
 The path defined by the sequence of line segments which connect the
 consecutive <Locations> that make up a <Feature Edge> 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 <Base Vertex> component of F shall appear exactly once
    as a component of F.

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

 3. M shall have the structure specified in the class definition
    of <Mesh Face Table>. In addition, the following conditions
    shall hold.

    3.1 The cell values corresponding to M's SE_INDEX_CODE_MESH_VERTEX
        <Table Property Description> component shall specify valid
        indices into F's <Base Vertex> list.

    3.2 If M has an SE_INDEX_CODE_ADJACENT_MESH_FACE
        <Table Property Description> component T, T shall specify
        valid indices into M's set of mesh faces. Furthermore, F
        shall not have any <Property Table> component classified
        as either ECC_MESH_SOLID_SET or as
        ECC_MESH_SOLID_PROPERTY_SET.

 4. 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.

 5. 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. In addition, P's
    SE_INDEX_CODE_MESH_FACE <Axis> component shall specify valid
    indices into M's mesh faces.

 6. 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. In addition, the cell
    data corresponding to P's SE_INDEX_CODE_MESH_FACE
    <Table Property Description> component shall specify valid
    indices into M's mesh faces.

 7. 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. In addition, F shall have
    a <Property Table> P2 classified as ECC_MESH_SOLID_SET, and P1's
    SE_INDEX_CODE_SOLID_ELEMENT <Axis> shall specify valid indices into
    P1's solid elements.

Rationale:
 1. All the <Base 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_parameters.

 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_parameters 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>
 instance shall equal the number of <Texture Coordinate> components for each
 <Base Vertex> and <Tack Point> within the object tree rooted at that
 <Geometry>.

 <Image Mapping Function> instances referenced by <Feature> 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> is used to specify a non-planar projection
   (e.g., spherical, cylindrical), it shall use an <Image Anchor>
   component, and the <Geometry> to which the <Image Mapping Function> 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> instances are
 attributes for geometry that is to be derived by the consumer for the
 <Feature>. Since <Texture Coordinate> and <Tack Point> instances are not
 applicable to <Feature> instances, such <Image Mapping Function> instances
 shall be specified with <Image Anchor> components.

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

                    <Polygon>
                       <>
     -----------------------------------------------
     |              |             |                |
    <Vertex>    <Vertex>      <Vertex>     <Image Mapping Function>
     <>            <>             <>               <>
     |              |             |                |
   <Texture     <Texture      <Texture     <Presentation Domain>
   Coordinate>   Coordinate>   Coordinate>  { SE_PRES_DOM_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 Functions>, so each of its <Vertex> components will have 2
    ordered <Texture Coordinate> components, one for each
    <Image Mapping Function>.

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

 3. See <Texture Coordinate Table> for examples of how to use
    <Image Mapping Functions> with <Texture Coordinates> specified
    in tables.

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_ELEM_CODE_TYP_ATTRIBUTE,
     |      |                 { EAC_PROPERTY_SET_SPATIAL_DOMAIN }
     |      |     value = { SE_PDV_ENUMERANT_CODE,
     |      |               { EEC_PRPSETSPATDMN_SURFACE }}
     |      |
     |      |---- <Property Value>
     |      |     meaning = { SE_ELEM_CODE_TYP_ATTRIBUTE,
     |      |                 { EAC_WATER_BODY_PROPERTY_SET_ACOUSTIC_TYPE }
     |      |     value = { SE_PDV_ENUMERANT_CODE,
     |      |               { EEC_WTRBDPRPSTACTY_LOSS }}
     |      |
     |      |---- <Property Value>
     |            meaning = { SE_ELEM_CODE_TYP_ATTRIBUTE,
     |                        { EAC_FREQUENCY }
     |            value       = { SE_PDV_FLOAT, { 100 }}
     |            value_scale = ESC_UNI
     |            value_unit  = EUC_HERTZ
     |
     |
     |---- <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_ELEM_CODE_TYP_ATTRIBUTE,
            |                 { EAC_PROPERTY_SET_SPATIAL_DOMAIN }
            |     value = { SE_PDV_ENUMERANT_CODE,
            |               { EEC_PRPSETSPATDMN_SURFACE }}
            |
            |---- <Property Value>
            |     meaning = { SE_ELEM_CODE_TYP_ATTRIBUTE,
            |                 { EAC_WATER_BODY_PROPERTY_SET_ACOUSTIC_TYPE }
            |     value = { SE_PDV_ENUMERANT_CODE,
            |               { EEC_WTRBDPRPSTACTY_LOSS }}
            |
            |---- <Property Value>
                  meaning = { SE_ELEM_CODE_TYP_ATTRIBUTE,
                              { EAC_FREQUENCY }
                  value       = { SE_PDV_FLOAT, { 2000 }}
                  value_scale = ESC_UNI
                  value_unit  = EUC_HERTZ

FAQs:
     None.

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

Constraint Name: Legal Time Ranges

Definition:
 1. For <Absolute Time Point>,
    1.1 hour shall be between -1 and 23 inclusive, where -1 indicates that
        hour is not applicable.
    1.2 minutes shall be between -1 and 59 inclusive, where -1 indicates that
        minutes is not applicable.
    1.3 seconds shall be between -1 and 59; that is, -1 <= seconds < 59.0,
        where -1 indicates that seconds is not applicable.

 2. For <Absolute Time Interval> and <Relative Time Point>,
    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 59, i.e. 0 <= seconds < 59.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 59; that is, 0 <= seconds < 59.0.

Rationale:
 Absolute times are sometimes used to specify dates, without specifying
 a specific time for that date, hence "not applicable" is needed for
 hours, minutes, and seconds.

 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 59 should be expressed in minutes.

Example:
 1. To specify a date of 31 December 1999 with an <Absolute Time Point>,
    set year = 1999, month = SE_MONTH_DECEMBER, day = 31, but set
    hour = minutes = seconds = -1 to indicate that only the date (not
    the exact time) is being specified.

FAQs:
     None.

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

Constraint Name: Level Of Detail Related Organizing Principle

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

 1. The <Base Level Of Detail 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 Level Of Detail Data> overlap,
    neither shall be a subset of the other.

    2.1 For <Distance Level Of Detail Data>, 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 <Volume Level Of Detail Data>,

        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 Level Of Detail 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 Level Of Detail Data> 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 Level Of Detail Data> 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 Level Of Detail Data> and
    - "sphere with radius 5 metres centred at 0,0,0" for <Volume Level Of
      Detail Data>.

 2. Range-based components and index-based components will not be attached to
    the same <Level Of Detail 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 <Base Vertex> component of G shall appear exactly once as a
    component of G.

 2. No two <Base 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 <Base 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 <Base 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.

 <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
                     originators shall be a non-empty string

 <Description>       abstract shall be a non-empty string

 <Keywords>          keyword_array shall be non-NULL

                     For each entry in keyword_array, the thesaurus
                     field shall contain a non-empty string. To indicate that
                     no thesaurus is applicable, the thesaurus
                     field shall have the value "NONE".

                     For each entry in keyword_array, the keyword_list
                     shall be a non-empty string, where keywords are
                     separated by semicolons.

                     For any two entries in keyword_array, either the
                     code fields or the thesaurus fields shall have
                     different values.

 <Point Of Contact>  person_or_position shall be a non-empty string

                     organization shall be a non-empty string

                     address shall be a non-empty string

                     voice_phone shall be a non-empty string

                     email_address, if provided, shall be a
                     comma-separated list of syntactically valid
                     e-mail addresses

                     web_site, if specified, shall be a comma-separated
                     list of syntactically valid URLs

 <Process>           description shall be a non-empty string

 <Source>            description shall be a non-empty string

Rationale:
 This is consistent with the CSDGM metadata standard which
 requires these fields and the ISO/DIS 19115 Metadata
 Standard which allows for these fields.

Example:
 1. For <Point Of Contact>, web_site = SE_STRING_DEFAULT is valid,
    and web_site = { SE_LOCALE_DEFAULT, 21, "http://www.sedris.org" }
    is valid, but web_site = { SE_LOCALE_DEFAULT, 3, "N/A" } is not.

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>.

    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 Links>,
        and if M provides controlling <Variables> to those
        <Control Links> 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 <Locations> under a <Model> shall be expressed in the spatial
    reference frame defined by that <Model>.

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> defined in a geodetic spatial reference frame may only be
    instanced within an <Environment Root> with matching geodetic spatial
    reference frame parameters.

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

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

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

FAQs:
 Q. Are model <Locations> restricted to LSR and the spatial reference frames
    found in a transmittal's <Environment Root> instances?
 A. No.  A <Model Library> 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 <Model Library> transmittal might not have any <Environment
    Root> instance 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 Location 2D> instance in an
    LSR <Model>?
 A. As explained in <Reference Surface>'s FAQ list, when an <LSR Location 2D>
    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> 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> has a <Property Value> component with
    meaning = { SE_ELEM_CODE_TYP_ATTRIBUTE,
                { EAC_PRIMARY_MATERIAL_TYPE }} and its value is
    EEC_PRIATTY_ASPHALT. This is inherited by all the <Polygons> of
    the union, so that if a <Polygon> represents a section of asphalt,
    it need not specify any further information.

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

                <Union Of Primitive Geometry>
                          <>
                          |
                          |----------------
                          |               |
                       <Polygon>    <Property Value>
                          <>        meaning =
                          |          { SE_ELEM_CODE_TYP_ATTRIBUTE,
                                      { EAC_PRIMARY_MATERIAL_TYPE }}
                          |         value.value_type = SE_PDV_ENUMERANT_CODE
                          |         value.u.ee_code = EEC_PRIATTY_ASPHALT
                          |
                     <Property Value>
                     meaning = { SE_ELEM_CODE_TYP_ATTRIBUTE,
                                 { EAC_PRIMARY_MATERIAL_TYPE }
                     value.value_type = SE_PDV_ENUMERANT_CODE
                     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> (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 <Models> and/or <Environment Root>.

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> or <Environment Root> needs to use another <Model>, use a
 <Feature Model Instance> or <Geometry Model Instance>. If only a portion of
 the <Model> is desired for reuse, it 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> with <Geometry Hierarchy> association. This
 association means that the <Feature> is an alternate representation of
 the <Geometry Hierarchy>. A terrain <Feature> 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> under the <Environment Root> may associate
    with an "F15" <Polygon>, since a terrain <Feature> 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 I haven't
    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: Oct Tree Related Organizing Principle

Definition:
 For any oct tree-related organization OTRA, whether an
 <Oct Tree Related Geometry> or an <Oct Tree Related Features>,

 1. The organization shall have a <Spatial Domain> component,
    defining the bounding volume that the oct tree is
    organizing into octants. Since a volume is being
    specified, this <Spatial Domain> 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 Domain> 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 Domain>.

    2.2 Each octant's <Spatial Domain> 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 Domain>
        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 oct tree-related organization shall provide a <Spatial Domain>,
    so that the data provider specifies the bounding volume that the
    oct tree is dividing into octants.

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

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

 4. These <Spatial Domain> instances shall be 3D, because
    the concept of an oct tree is inherently 3D.

Example:
     None.

FAQs:
 Q. Why specify a <Spatial Domain> for each branch of an Oct Tree? 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>
        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>
        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 <Base 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 <Base 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 <Base 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: Precedence of Attribute Set Index

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

 <Geometry> and <Features> may contain an ordered list of <Attribute Set
 Index> instances. If a <Geometry> or <Feature> contains references to more
 than one <Attribute Set> and there is a clash between the attribute objects
 they contain, then attribute objects contained in <Attribute Sets> referenced
 first in this ordered list have precedence over those contained in
 <Attribute 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> or <Feature>. 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> or <Feature>
               is used. If the clash is between objects in <Attribute Sets>,
               then the object contained in the <Attribute Set> that is
               referenced earliest in the list of <Attribute Set Index>
               instances is used.

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

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

 And so on.

Rationale:
 Objects contained directly by <Geometry> or <Features> are
 more closely related to the <Geometry> or <Feature> than those
 contained in an <Attribute Set>; they will be specific while
 those in an <Attribute Set> will be more generic.

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

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

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

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

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

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: EMC_SIGNIFICANT_DIGITS, EMC_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 EMC_MINIMUM_VALUE and C2 specifies
        EMC_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 EMC_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: Quad Tree Related Organizing Principle

Definition:
 For any quad tree-related organization QTRA, whether a
 <Quad Tree Related Features> or a <Quad Tree Related Geometry>,

 1. QTRA shall have a <Spatial Domain>.

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

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

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

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

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

        2.3.1 If a branch with SE_QUADRANT_NORTHWEST is present,
              its <Spatial Domain> 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_NORTHEAST quadrant's
                      <Spatial Domain>, if present, and

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

        2.3.2 If a branch with SE_QUADRANT_NORTHEAST is present,
              its <Spatial Domain> 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 Domain>,

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

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

        2.3.3 If a branch with SE_QUADRANT_SOUTHWEST is present,
              its <Spatial Domain> 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 Domain>,

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

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

        2.3.4 If a branch with SE_QUADRANT_SOUTHEAST is present,
              its <Spatial Domain> 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_SOUTHWEST quadrant's
                      <Spatial Domain>, if present, and

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

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

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

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

 3. The <Spatial Domain> 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> specified by the <Property Table Reference>
    shall be a component of a <Data Table Library>.

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

 3. The <Axis> 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>.

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 Vectors> and <World 3x3> 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 Vectors> inherit the <Positional Light>'s <Location>
    by this rule.

FAQs:
 Q. How does choice of Location component affect <Reference Vectors>
    in <Models> 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 into an <Environment Root> or
    another model, the SRF of which has a curvilinear coordinate system
    such as Geodetic, the effect may be noticeable with a large <Model>.
    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> 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> 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> <Locations> (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> in this example is a <Union Of Features>.

                     <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 <External
    Feature Face Ring> containing 3 <Feature Edges> as follows:

                       <External 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>'s
    state_values, as well as the return types of the <State
    Control Link>'s <Expressions> (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 <State Data> 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 Point>, <Absolute Time Interval>, and
 <Relative Time Interval> may each have a component
 <Absolute Time Point>, and the restrictions on their
 field values depend on the value of the <Absolute Time Point>
 component, when it is present.

 1. If an <Absolute Time Point> is present with day = -1, then
    1.1 for <Absolute Time Interval> and <Relative Time Point>,
        delta_days = 0.
    1.2 for <Relative Time Interval>, delta_start_days = delta_stop_days = 0.

 2. For <Absolute Time Interval> and <Relative Time Point>, if an <Absolute
    Time Point> is present with day <> -1 and month = SE_MONTH_ANY, then
    delta_days shall be in the range
         (1 - day) to (30 - day)
    where day is the <Absolute Time Point>'s day field.

    Note that delta_days is allowed to be negative for this case.

 3. For <Absolute Time Interval> and <Relative Time Point>, if an <Absolute
    Time Point> is present with day <> -1, month = SE_MONTH_USE_DAY_OF_YEAR,
    and year = -1, then delta_days shall be between 0 and 365 inclusive.

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

 5. For any <Absolute Time Point>, if month = SE_MONTH_USE_DAY_OF_YEAR, then
    day CANNOT = -1.

Rationale:
 1. Since an <Absolute Time Point> with day = -1 indicates that day is not
    applicable, no meaningful delta values can be applied to the day value
    for this case.

 2. <Time Intervals> that are referenced to an <Absolute Time Point> with
    month = SE_MONTH_ANY are 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 = -1, the year is assumed to be a 365-day year.

 4. Rule 4 only applies to the cases explicitly stated by the rule.

 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 Point>
 with month = SE_MONTH_ANY 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 not referenced to an
 <Absolute Time Point> with month = SE_MONTH_ANY 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: Unique ID Field

Definition:
 For any class that has an ID field, the ID is unique for all objects of
 that class within a given transmittal.

 Specifically, within the component tree of a given <Transmittal Root>:
 1) No two <Camera Point> instances may have identical values for their
    ID fields.

 2) No two <Feature ID> instances  may have identical values for their
    ID fields.

 3) No two <Geometry ID> instances  may have identical values for their
    ID fields.

Rationale:
 IDs exist to uniquely identify objects in a given context; consequently,
 they shall be unique to each object of a given class.

Example:
     None.

FAQs:
     None.

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

Constraint Name: Universal Feature Face Level 3

Definition:
 <Universal Feature Face> instances are used only at
 feature topology level 3 and higher.

Rationale:
 A <Universal Feature Face> is used to represent the universe
 "outside" a complete topological surface, which is specified
 only for level 3 or higher, in which every topology primitive
 is required either to be a face itself, or to lie within the
 bounds of a face.

Example:
     None.

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.