The SEDRIS Data Representation Model (DRM) currently consists of a few hundred classes, which can be somewhat intimidating. However, the complete list of DRM classes can be grouped into a few broad categories. Only a few of these categories are relevant to the discussion of attribute inheritance and context, namely:

• <Primitive Feature> and its subclasses


• <Primitive Geometry> and its subclasses
• <Aggregate Feature> and its subclasses, each of which organizes one or more collections of <Primitive Feature> instances


• <Aggregate Geometry> and its subclasses, each of which organizes one or more collections of <Primitive Geometry> instances
• "Attribute" objects, which describe attributes of geometry or features

Attribute objects can be attached to various levels of an <Aggregate Feature> (or <Aggregate Geometry>) and 'inherited' by the various features (or geometry) that are organized by that aggregate. That is, <Aggregate Geometry> instances (and <Aggregate Feature> instances) inherit a list of attribute components from their 'ancestors'.

Remembering that a SEDRIS transmittal is acyclic when considered in terms of aggregate / component relationships, one object A is the ancestor of another object B when A aggregates (contains) B as a component. For example, a <Polygon> is an ancestor of its <Vertex> components, and a <Union Of Primitive Geometry> can be an ancestor of a <Polygon>.

The purpose of attribute inheritance is to indicate that a collection of <Primitive Feature> instances (or <Primitive Geometry>) all have the same attribute as a component. Data providers exploit this by attaching the component to a "higher" object in the hierarchy, rather than attaching it to each individual primitive object. This "higher" object eventually aggregates the primitive objects, which inherit the component from this "higher" ancestor object. This allows a data provider to explicitly share individual object instances among many aggregates efficiently, in a way that is useful to a data consumer.

Inheritance is transitive. That is, when a <Geometry> or <Feature> inherits a component, that component may be treated as if it were attached directly to the <Geometry> or <Feature> that inherited the component.

Consider Figure 2-1.

<Aggregate Geometry> "A" has inheritable component "I" and <Union Of Primitive Geometry> "B" as components. We say that

• "A" is the ancestor of "B"
• "I" is directly attached to "A"
• "I" is inherited by "B" from "A"

A component is inherited merely by existing as a component of an ancestor, and by satisfying the inheritance rules applicable to its class and context. If a component satisfies these rules, then it is inherited; inheritance is not optional. If a component does not satisfy the rules of inheritance, then it cannot be inherited.

The API provides support for retrieving the list of inherited components of a given object, via both SE_InitializeComponentIterator() and SE_InitializeInheritedComponentIterator(), and for retrieving only the list of directly attached components (via SE_InitializeComponentIterator()). A consumer is not required to use the functionality of the API to retrieve inherited components; however, the inherited components are defined as applying to the data whether or not the user chooses to retrieve them. In addition, a data consumer who wishes to exploit inheritance with an eye toward saving memory through object reuse may choose to distinguish between objects that are directly attached and those that are inherited, but is not required to do so.

As stated earlier, inheritance is transitive. All the inherited components of an <Aggregate Geometry> are inherited in turn by any <Primitive Geometry> and <Property Grid Hook Point> instances aggregated by that <Aggregate Geometry>, subject to the rules of inheritance. Similarly, all the inherited components of an <Aggregate Feature> are inherited in turn by any <Primitive Feature> instances aggregated by that <Aggregate Feature>.

Note that the <Geometry Model Instance> and <Feature Model Instance> classes do not participate in attribute inheritance. If a data provider intends that attribute objects within a <Model> should be determined on an instance-by-instance basis, the the data provider shall design the <Model> with an <Interface Template> and an appropriate set of <Control Link> and <Variable> instances, so that when the <Model> is instanced, the desired attribute objects can be controlled via the model instance / <Interface Template> mechanism. See Part 4, Volume 5, Control Link Technical Guide, for further details.

In addition to inheriting components, there are 2 cases in which link objects are inherited: the classification related and time related organizations. The same rules that apply to classification related aggregations also apply to time related aggregations. An aggregate, primitive, or <Property Grid Hook Point> member of a classification related aggregation inherits a <Classification Data> component identical to the information in the link object between the component and the classification related aggregation. Consider the example in Figure 2-2.

The <Union Of Primitive Geometry> component inherits "A", while the <Property Grid Hook Point> inherits "B", subject to the rules of inheritance.