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

NOTE: Since an <Attribute Set> may contain some objects that are <Feature>-specific and some that are <Geometry>-specific, there is a rule stating that for <Feature> instances, only the attributes that are legal for the <Feature> class are used, while for <Geometry>, only the attributes that are legal for the <Geometry> class are used.

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 <Attribute Set> that appears at the same level, then the directly attached component overrides the component overrides the component from the <Attribute Set>.

Currently, <Colour> is subject to the simple override rule.

At any level, a set of <Image Mapping Function> instances 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> instances to its components.

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

A <Base Reference Vector> is required to have a defined point of origin. In order for the unit_vector field of a <Base Reference Vector> to be defined in a spatial reference frame (SRF), that SRF shall have a compatible vector space structure. Several of the SRFs supported by SEDRIS (e.g. geodetic) do not have vector space structure. When a <Base Reference Vector> is defined in such an SRF, SEDRIS actually embeds an LTP space in that non-vector SRF at the vector's point of origin, so that the vector is actually defined inside that LTP space. See the <Base Reference Vector> class, and the DRM and SRM definition for the various SRFs supported by SEDRIS, for a more detailed discussion of these LTP spaces.

If a <Base Reference Vector> has a directly attached <Location> component, that is its point of origin. However, in many contexts where <Base Reference Vector> appears in the DRM, the vector can unambiguously inherit a <Location> from the object that aggregates the <Base Reference Vector> rather than specifying a separate <Location>, which would be required to be the specific instance it should inherit in order to be valid. 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> 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 <Base Reference Vector>.

In the case of a <Vertex With Component Indices> that refers to a <Location Table>, a <Base Reference Vector> inherits the <Location> indexed by the <Vertex With Component Indices>.

A directly attached <Property Description> instance overrides an inherited instance if the "newer" <Property Description> has the same meaning. Otherwise, both <Property Description> instances apply and are inherited further down in the tree.

In other words, two <Property Description> instances conflict only if they have the same meaning.

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, then that <Property Value> is considered to be qualified by the <Property Value> and <Property Characteristic> components of the matching <Property Description>.

A directly attached <Property Table> instance overrides an inherited instance if the "newer" <Property Table> has the same qualified classification. Otherwise, both <Property Table> instances apply and are inherited further down in the tree.

In other words, two <Property Table> instances conflict only if they have the same qualified classification.

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.

In other words, two <Property Table Reference> instances conflict only if the referenced <Property Table> instances conflict.

A directly attached <Property Value> instance overrides an inherited instance if the "newer" <Property Value> has the same meaning. Otherwise, both <Property Value> instances apply and are inherited further down in the tree.

In other words, two <Property Value> instances conflict only if they have the same meaning.

See also rules for <Property Description> above.