All topology in a SEDRIS transmittal is included via topology hierarchy instances, either <Feature Topology Hierarchy> instances (in the case of feature topology) or <Geometry Topology Hierarchy> instances (in the case of geometry topology). The general organization of and constraints upon feature topology and geometry topology are similar, so without loss of generality this document will discuss topology in terms of feature topology only, with the understanding that the principles of geometry topology can be extrapolated.

In accordance with the <<Constraints On Associates>> and <<Constraints On Components>> constraints, the topology hierarchy components of an <Aggregate Feature> or <Aggregate Geometry> shall organize all the topology instances referenced by the aggregate, and no other instances. If an aggregate A has a topology hierarchy TH, then all the topological primitives referenced by the primitives of A shall be among those organized by TH.

Consequently, each <Feature Model> containing topological primitives would contain its own topology hierarchy instances to organize them in its component tree, and each <Environment Root> instance organizes its own topology. Note that the topology of a <Feature Model Instance> is organized by its <Feature Model>'s component tree and hierarchy, rather than by the instancing context.

In the case of ITR, a data provider would be expected to provide appropriate <Feature Model Instance>s or (in the context of <Environment Root> features) references to <Feature Representation> instances rather than referencing the topology in another component tree directly. As the interaction of ITR and various syntactic and practical considerations unfolds in actual usage, these interactions are expected to develop more explicit constraints and tighter restrictions.

As specified by the aggregate classes, an aggregate with a topology hierarchy component represents an independent (that is, free-standing and disconnected from its surroundings) topological surface. Frequently, this means that in the scope of an <Environment Root>, only the <Aggregate Feature> component of the <Environment Root> itself will have a topology hierarchy component, which organizes the feature topology referenced within its scope. (Similar criteria apply to geometry topology.)

Each topology hierarchy instance specifies the level of topology that is supported, providing an indication of the quality of the topological information provided. Higher-level topology is easier to consume, because more and more relationships have been pre-computed, but it therefore requires more work on the part of the data provider.

Every data provider who provides topological objects at all provides at least level 0 topology. Level 0 is the easiest level to produce, and the most complex to consume, because it applies the least possible quality restrictions on the topology involved. At this level, topological objects are present and are required to be syntactically and semantically valid, but the data provider is not required to avoid duplicating information. For example, multiple <Feature Node> instances may be present for a given position in space, so the burden of deriving complete information about the relationships between various objects is largely placed on the consumer.

Some of the semantic restrictions that are enforced even at level 0 include, but are not limited to, restrictions designed to prevent degenerate rings for faces, such as permitting an edge to be included in a ring at most twice, once for each orientation. See the constraints list for further details.

At level 1, the data provider guarantees that no two <Feature Node> instances have the same coordinates in space. This ensures that the consumer does not have to detect the presence of several <Feature Node> instances which really correspond to the same conceptual node. All topological information about a node is guaranteed to be provided via the same <Feature Node> instance.

At level 2, the data provider not only ensures that <Feature Node> instances are unique (as in level 1), but that <Feature Edge> instances do not intersect or overlap one another except at common <Feature Node> instances. This removes the burden of detecting intersections from the consumer.

Level 3 is even more friendly to the consumer, while requiring the data provider to ensure that the following criteria have been met. Not only does the topology have to meet the standard set by level 2, but all <Feature Node> instances lying within the boundaries of <Feature Face> instances are required to supply the association relationships indicating that this is the case, and vice versa, removing the burden of testing for containment from the consumer. (At lower levels of topology this information may be supplied, but it isn't guaranteed to be complete.)

Furthermore, at level 3, <Feature Face> instances are required (they are optional at lower levels of topology). The data provider shall provide exactly 1 <Feature Face> instance FF for the transmittal being produced, where FF represents the 'universe' outside the topology of the transmittal; its internal boundaries therefore represent the external boundaries of the topology. The data provider shall also provide 1 or more <Feature Face> instances that partition the topological surface being represented. All <Feature Edge> instances shall lie on the boundary between two faces; that is, no <Feature Edge> shall lie inside a face, because the data provider would partition such a face so that it consisted of 2 faces, one on either side of the edge.

At level 4, the topology is at least partially 3-dimensional, so edges are no longer required to bound faces, although otherwise the requirements of level 3 are in force. Since only in 3D does the concept of 'front' and 'back' have any meaning, only at this level are <Areal Feature> instances provided with faces for which <Face Direction> may not have front = TRUE.