Temporal aspects of feature associations and dependencies

A reference to another feature (coded with @xlink:href) creates a dependency, which might bring "hidden changes" to the referencing feature properties. A typical case is the dependency between an Airspace horizontal projection and a GeoBorder, as discussed here: Geoborder for Airspace Border. A reference by @xlink:href is towards the complete feature rather than a single TimeSlice. 

For example, let's assume that a GeoBorder feature is defined with two TimeSlices, as indicated below: (only relevant parts are shown). 

<aixm:GeoBorder ...>
    <gml:identifier ...>abc123...
        <aixm:timeSlice>
          <gml:validTime>
            <gml:beginPosition>2013-05-02T00:00:00Z
            <gml:endPosition>2014-04-03T00:00:00Z
                    ...
        <aixm:timeSlice>
          <gml:validTime>
            <gml:beginPosition>2014-04-03T00:00:00Z
            <gml:endPosition>2014-12-11T00:00:00Z

This may have different consequences on the geometry of the referencing Airspace, depending on how the GeoBorder TimeSlices are positioned in time as compared with the Airspace TimeSlices.

In the first example, the Airspace and the referred GeoBorder Timeslices have identical validity period. There is no "hidden change" in this case because the GeoBorder has the same geometry for the whole duration of the Airspace TimeSlice shown in this example. The same can be said about the situation when the validity of the Airspace Timeslice is inside the validity period of the GeoBorder that it references

<aixm:Airspace ...>
    <aixm:timeSlice>
      <gml:validTime>
        <gml:beginPosition>2013-05-02T00:00:00Z
        <gml:endPosition>2014-04-03T00:00:00Z
         ...
              <gml:curveMember xlink:href="urn:uuid:abc123..."/>

The situation changes when the Airspace TimeSlice validity crosses the time instance between the first and the second GeoBorder Timeslice validity, as in the example below. 

<aixm:Airspace ...>
    <aixm:timeSlice>
      <gml:validTime>
         <gml:beginPosition>2013-08-22T00:00:00Z
         <gml:endPosition>2014-06-26T00:00:00Z
         ...
              <gml:curveMember xlink:href="urn:uuid:123..."/>

In this case, there is practically a "hidden change" in the Airspace geometry at '2014-04-03T00:00:00Z', because a different version of the GeoBorder (a different TimeSlices) becomes effective. 

In a database, a query for the (full) lateral limits of Airspace in the example above would yield different results depending on the required effective date. However, all properties of that Airspace in AIXM would remain unchanged. There is no visible Airspace property change, just an implied change of its geometry due to the GeoBorder modification. AIXM data providers should not be forced to create a new Airspace time slice when a GeoBorder changes. That's actually a benefit of references, since such time slice would contain no change at all because it would have the same link to the same GeoBorder instance. 

The same dependency may occur when an Airspace uses an AirspaceVolume that is derived from the geometry of another Airspace (as discussed here: Single volume with derived geometry or Using derived geometries).

The situation is different for features that have an actual geometry property that is impacted by the change (such as RouteSegment.curveExtent). If that property is not NIL, then it is practically an obligation to have a new TimeSlice if the position of a start/end  navaid/point changes. There are also properties, such as length and direction that might change in this case.