| 
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.
  | 
 | 
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.
  |  
 
 | 
 | 
Objects are not inherited unless they belong to a class that is designated
as inheritable. The following "attribute" class objects are never
inherited.
 
 |