Attribute Inheritance and Context Technical Guide
Section 3 - INHERITANCE AND CONTEXT

3.1 General Rules of Inheritance

As stated above, directly attached components always override - that is, logically replace - any conflicting inherited components. The definition of "conflicting" depends on the class of object. For example, directly attached components always override any conflicting attributes from a referenced <Property Set> instance or <Colour Table> instance.

3.2 Inheritable Components

The following classes are subject to simple replacement; that is, a directly attached component always overrides an inherited component, in the case of instances of these classes.

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

Class Rule
<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.

NOTE: Since an <Property Set> may contain some objects that are <Feature Representation>-specific and some that are <Geometry Representation>-specific, there is a rule stating that for <Feature Representation> instances, only the attributes that are legal for the <Feature Representation> class are used, while for <Geometry Representation>, only the attributes that are legal for the <Geometry Representation> 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 <Property Set> that appears at the same level, then the directly attached component overrides the component overrides the component from the <Property Set>.

<Colour>

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

<Image Mapping Function>

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.

<Location> Instances for <Reference Vector>

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 defined point of origin. In order for the unit_vector field of a <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. celestiodetic) do not have vector space structure. When a <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 <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 <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>, 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 <Reference Vector>.

<Property Description>

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>.

<Property Table>

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.

<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.

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

<Property Value>

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.

3.3 Classes of Attributes That Aren't Inherited

Objects are not inherited unless they belong to a class that is designated as inheritable. The following "attribute" class objects are never inherited.

Class Rationale
<Citation> <Citation> cannot be inherited due to their semantic meaning. The <Citation> at the top of any hierarchy specifies the bibliographic citation information for the collection as a whole; to reference any part of the collection specifically, that part would require its own <Citation>.
<Identification> A <Identification> should be specific to the instance that aggregates it.
<Keywords> <Keywords> cannot be inherited due to their bottom-up nature. The <Keywords> at the top of any hierarchy are a collection of the individual keywords that apply through the hierarchy, so they are built bottom-up in the hierarchy rather than being inherited top-down.
<Label> A <Label> is attached to exactly one <Feature Representation>, so it cannot be inherited to apply to other <Feature Representation> instances.
<Spatial Extent> <Spatial Extent> instances cannot be inherited due to the bottom-up nature of a <Spatial Extent>. For instance, an <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> <Responsible Party> instances are not inherited, because they appear infrequently in a typical transmittal - usually only once, as the mandatory <Responsible Party> of a <Transmittal Root>. Currently, the overhead of inheriting a <Responsible Party> is not considered to be worth the overhead.


Return to: Top of this Page, Table of Contents

Last updated: July 26, 2006 Copyright © 2006 SEDRIS