For information on this mechanism, review the following:

• <Hierarchical Table> and its subclasses.

  These classes exist to organize instances of classes that are formal components of "drm/classes/BaseVertex.htm"><Base Vertex>. The intent is to allow vertices with common components to explicitly share those components without the overhead of creating an association relationship.

• <Vertex With Component Indices>

  This class should only be used in conjunction with the <Hierarchical Table> mechanism (otherwise, the data provider would be paying the overhead of the presence of the index fields in memory without getting value for it). When used, appropriate <Hierarchical Table> instances shall be present in the aggregate path leading to the vertex such that the indices in use within its fields are valid.

• <Reference Vector With Location Index>

  This class should only be used in conjunction with the <Hierarchical Table> mechanism (otherwise, the data provider would be paying the overhead of the presence of the index field in memory without getting value for it). When used, appropriate <Hierarchical Table> instances shall be present in the aggregate path leading to the vertex such that the indices in use within its fields are valid. The data provider should be extremely careful when using this mechanism that the behaviour of resulting transmittals under coordinate conversion and transformation is as desired.

• The comments for the directly_attach_components parameters of the various initialize-component-iterator functions in the level 0 API.

  These parameters allow the consumer to request that the indices be resolved into (apparently) direct components before being presented to the consumer.