DRM objects that specify properties can be attached to various levels of a <Aggregate Feature> (or <Aggregate Geometry>) instance hierarchy and "inherited" by the various features (or geometry) that are organized by that aggregate. That is, an instance of <Aggregate Geometry> instances (or <Aggregate Feature>) inherits a list of properties from its aggregate.

Property inheritance and context applies to the following DRM classes:

1. <Primitive Feature> and its subclasses;
2. <Primitive Geometry> and its subclasses;
3. <Aggregate Feature> and its subclasses, each of which organizes one or more collections of <Primitive Feature> instances;
4. <Aggregate Geometry> and its subclasses, each of which organizes one or more collections of <Primitive Geometry> instances; and
5. DRM objects that specify attributes of geometry or features.

For the purposes of discussion, the following terminology will be established. One object A is the ancestor of another object B when A aggregates B as a component, or when A is an aggregate of an ancestor of B. B, in turn, is said to be a descendant of A. If A is an aggregate of B, B is said to be a directly attached component of A, to distinguish this case from cases where A is an ancestor but not an aggregate of B.

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> instances) all have the same attribute as a component. This allows 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. Thus, explicit sharing of individual object instances occurs efficiently among many aggregates.

Inheritance is transitive. That is, when a <Geometry Representation> or <Feature Representation> inherits a component, that component may be treated as if it were attached directly to the <Geometry Representation> or <Feature Representation> instance that inherited the component. 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 a <Aggregate Feature> are inherited in turn by any <Primitive Feature> instances aggregated by that <Aggregate Feature>.

The <Geometry Model Instance> and <Feature Model Instance> classes do not participate in attribute inheritance. If the attribute objects within a <Model> are to be determined on an instance-by-instance basis, <Model> shall have an <Interface Template> and an appropriate set of <Control Link> and <Variable> instances.

In addition to inheriting components, there are two 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.

If a component is directly attached to an object to associate a property with that object and the object is a member of an aggregating hierarchy, that component will override any similar component attached at a higher level in the aggregating hierarchy.

2.3.1 Overview

The following classes are subject to simple replacement. A directly attached component always overrides an inherited component in the case of instances of these classes.

1. <Base LOD Data>,
2. <Colour>,
3. <Data Quality>,
4. <Legal Constraints>,
5. <Light Rendering Properties>,
6. <Perimeter Data>,
7. <Presentation Domain>,
8. <Rendering Priority Level>,
9. <Rendering Properties>, and
10. <Security Constraints>,
11. <Time Constraints Data>.

The following classes are subject to more complex rules of inheritance:

1. <Classification Data>,
2. <Property Set Index>, and
3. <Image Mapping Function>.

2.3.2 <Classification Data>

<Classification Data> instances are not inherited in the general case, but only in the specific context of a <Union Of Features> or <Union Of Geometry> instance. The union is used to explicitly distinguish between the cases of a union representing a single environmental object versus the case of a union representing a collection of environmental objects, where in the latter case the <Classification Data> is being shared by the components of the union for efficiency of representation.

In the case of a union representing a single environmental object, the union_reason field will value  CLASSIFIED_OBJECT. In this case, the <Classification Data> instance is not inherited by the components of the union. In the case of a union representing a collection of environmental objects, the union_reason field will have some other value. In this case, the <Classification Data> instance is inherited by the components of the union. If they in turn are union instances, further property inheritance behaviour is determined by their own union_reason field values. If the components of the union are not themselves unions, property inheritance stops at that level for the <Classification Data> instance.

2.3.3 <Property Set Index>

<Property Set Index> is not inherited itself. Instead, the applicable attribute objects from the referenced <Property Set> are treated as if they replaced the <Property Set Index> for the purposes of inheritance. For each of those attribute objects, the individual, standard inheritance rules for their classes apply.

A <Property Set> may contain some objects that are <Feature Representation> specific and some that are <Geometry Representation> specific. In this case, <Feature> instances only use the properties that are legal for the <Feature Representation> class, while <Geometry Representation> instances only use the properties that are legal for the <Geometry Representation> class.

The general rule of “lower” components overriding “higher” components still applies. As an extension of that rule, if there is a conflict between a directly attached component and an attribute from a referenced <Property Set> that appears at the same level, the directly attached component overrides the component from the <Property Set>.

2.3.4 <Image Mapping Function>

At any level, a set of <Image Mapping Function> objects can be attached; they are treated as a group. Each set completely replaces the previous set, even if the set contains only one <Image Mapping Function>. In other words, any object with one or more direct <Image Mapping Function> components will not inherit any <Image Mapping Function> components from its ancestors, but instead will pass on its own direct <Image Mapping Function> components to its components.

2.3.5 <Location>s for <Reference Vector>s

In general, <Location> is not inherited; it is covered by a special rule specific to <Reference Vector>.

A <Reference Vector> is required to have a specified point of origin. In order for the unit_vector field of a <Reference Vector> to be specified in an SRF, that SRF shall have a compatible vector space structure. Several of the SRFs supported by this part of ISO/IEC 18023 (e.g., geodetic) do not have vector space structure. When a <Reference Vector> is specified in such an SRF, an LTP space is embedded in that non-vector SRF at the vector's point of origin, so that the vector is actually specified inside that LTP space.

If a <Reference Vector> has a directly attached <Location> component, that is its point of origin. However, in many contexts where <Reference Vector> appears in the DRM, the vector can unambiguously inherit a <Location> from the object that aggregates the <Reference Vector> rather than specifying a separate <Location>. The rule for this inheritance, expressed by the constraint <<Required Reference Vector Location>> is that, given any object A with a <Location> component (or an ordered list of <Location> components), that object's first <Location> component becomes the default <Location> in the context of the aggregation tree rooted at A.

In the cases of those classes specified by the <<Required Reference Vector Location>> constraint, in which multiple <Location> components are present, and inheritance would be ambiguous, a directly attached <Location> is required for the <Reference Vector>.

2.3.6 <Property Description>

A directly attached <Property Description> component overrides an inherited instance if the "newer" <Property Description> instance applies  to the same envrionmental attribute, as indicated by its meaning field value. Otherwise, both <Property Description> instances apply and are inherited further down in the tree. Thus, two <Property Description> instances conflict only if they apply to the same property.

If a <Property Description> is a component of an object instance A and a <Property Value> with matching meaning is in the component tree rooted at A, that <Property Value> is considered to be qualified by the <Property Value> and <Property Characteristic> components of the matching <Property Description>.

2.3.7 <Property Table>

A directly attached <Property Table> object overrides an inherited instance if the newer <Property Table> has the same qualified classification. Otherwise, both <Property Table> objects apply and are inherited further down in the tree. Thus, two <Property Table> instances conflict only if they have the same qualified classification.

2.3.8 <Property Table Reference>

A directly attached <Property Table Reference> instance overrides an inherited instance if both referenced <Property Table> instances have the same qualified classification. Otherwise, both <Property Table Reference> instances apply and are inherited further down in the tree. Thus, two <Property Table Reference> instances conflict only if the referenced <Property Table> instances conflict.

2.3.9 <Property Value>

A directly attached < Property Value> instance overrides an inherited instance if the newer <Property Value> applies to the same environmental attribute, as indicated by its meaning field value. Otherwise, both <Property Value> instances apply and are inherited further down in the tree. Thus, two <Property Value> instances conflict only if they specify values for the same property.

Property inheritance does not apply to all kinds of property classes. Those classes to which property inheritance does not apply are discussed below, including the reasons why property inheritance does not apply.

Instances of <Citation> cannot be inherited. The <Citation> at the top of any hierarchy specifies the bibliographic citation information for the collection as a whole. Referencing any part of the collection specifically requires its own <Citation>.

Instances of <Keywords> apply only to the object to which they are attached, because the keywords applicable at the level of a hierarchy at which a <Keywords> instance is specified are built up from smaller subsets of keywords derived from lower levels of that hierarchy. Consequently, property inheritance does not apply to instances of <Keywords>.

An <Identification> instance is specific to the DRM object that aggregates it, describing the hierarchy as a whole.

<Spatial Extent> instances cannot be inherited due to the bottom-up nature of a <Spatial Extent>.

EXAMPLE:  A <Environment Root> may cover a <Spatial Extent> of thousands of square kilometres, while one of its <Polygon> instances covers only a square metre or two.

<Responsible Party> instances are not inherited.