9 Propagation of Data Objects

Many applications take one or more input objects and generate one or more output objects. In such cases, applications have to make decisions about what parts of the input objects are to be propagated to the outputs, guided by the following rules:

• General-purpose applications will copy extensions (cf. Section 8) to the same location within an output structure provided their parent structure has been propagated; specialist applications are, of course, allowed to process individual items within the extensions they understand.
• Items whose properties are well understood in the context of a given application may be processed by that application.
• Items whose properties are not well defined in the context of a given application must not be propagated by that application. Thus, items or structures rendered meaningless, wrong or even dubious by the processing must not be propagated. The ad hoc approach to doubtful cases is strongly discouraged.
• “Rogue” objects—anything outside the Starlink standard—should be ignored.
• Applications are not allowed to pollute standard structures with rogue objects; all application-specific items must reside in registered extensions, within one of the [MORE] structures.

By stipulating that rogue objects must be ignored, we avoid the problem of what should happen if a component of the same name already exists in the output structure. Also, not having to worry about rogue objects will greatly simplify the checking and revision of application code that would follow any revision or extension of the standard structure definitions in the future.

In cases where applications access more than one composite data structure to generate a single output structure, e.g. arithmetic of two data arrays, there are additional problems about the propagation of certain data objects. These are mainly descriptive items e.g. [HISTORY], [LABEL]. Should one, all or none of these data objects be propagated? If the third rule above is followed rigorously the answer is none, but many useful and relevant data objects would then be lost. To assist in deciding whether they can be retained, the concept of a dominant or principal data array is introduced, whose various associated items will be the ones propagated. By convention, the application’s interface file will be arranged so that, of the parameters specifying data arrays, the principal array will be the first in sequence. In many cases, it will be necessary to advise the user which items have been propagated and which have been lost; if the result is unsuitable, the application can then be re-run with the parameters specified in a different order, or other programs can be run to fine-tune the result—by replacing a label, for example.

The specific rules for HISTORY are as follows.

If there is a principal array, its history should be propagated with a record appended for the latest operation, which could include the name and title of the secondary data arrays. If the data arrays are equally important, it is probably best to create a new [HISTORY] structure, again with the names/titles of its parents. However, for cases where this option will not suffice, a special HDS editor application will be provided for grafting in history records taken from existing $<$HISTORY$>$ structures.