Not all NDF data structures are created from scratch and then
successively modified in situ. More commonly, they are produced
by copying a certain amount of information from related input datasets
while applying the required modifications in the process. In this
situation, one of the input datasets is normally regarded as
primary, and it is from this that the output NDF inherits most
of its
ancillary information by the process termed propagation (see
§).
To be complete, a description of the processing history of an NDF generated in this way would need to contain the processing histories of all the input datasets which have contributed to it. However, it is generally regarded as unnecessary to retain this wealth of history information as it would lead to exponential growth in the amount of information to be processed and stored. A more practical proposition, and the one supported by the NDF_ library, is to propagate the past history from only the primary input dataset to the output, and then to update this by appending a new record to reflect the action of the current application.
As a consequence, a complete record of all previous events will not be
present in the new NDF. However, if the history information recorded
by each application includes the full names of its input datasets,
then these can be inspected separately to recover any further
information. This keeps the amount of history information within
reasonable bounds. Because the NDF_ library stores the name of the
NDF in which a history component resides whenever it creates a
new history record, an audit trail is
automatically produced which allows the ``ancestors'' of any dataset
(i.e. those datasets from which the history component has
previously been propagated) to be identified.
Propagation of history component information takes place in a
similar way to the propagation of any other NDF component (see
§) and is typically performed by the NDF_PROP (or
NDF_SCOPY) routine. In this context, the history component is
considered ``safe'' in the sense that its validity is not affected by
the processing performed by most applications. It is therefore
propagated by default, and you must explicitly specify if you do not
want it to be propagated. This means that in practice most
applications need take no action to ensure that history information is
kept, since it will be maintained automatically via the
propagation and default history recording mechanisms.