next up previous 62
Next: Bad-Pixel Methods
Up: Starlink Standard Data Structures
Previous: Errors

History

For the storage of information related to the genealogy and processing history of a data frame, the Birmingham/Asterix design and subroutine-interface library has been adopted. Therefore the structure is named [HISTORY] and has TYPE $<$HISTORY$>$. (See Asterix Programmer Note 86_008.) A [HISTORY] structure describes the object in which it appears at the top level; it never describes anything at higher levels. This usually means that one history applies to one main data array.

History is optional and is under the control of applications--only they know whether they have done anything important to a file, and which parameters are important, though the user will always have the opportunity to add commentary via various patching and notepad utilities. There should be a logical parameter in applications to enable/disable history recording, which is normally defaulted in the interface file to disabled. Applications which do not modify or create structures containing [HISTORY] (e.g. $<$NDF$>$) do not need to update it -- a display application, for example, would not have to write a history record.

History records must not be regarded by applications as machine readable--they must not be used to specify parameters or to control processing, even to re-enact automatically a processing sequence. They are present to assist the user: ``What did I do to these data?'', ``Did I flat-field this image?''.

History records should be brief.

Details are given in $<$HISTORY$>$ Structure.


next up previous 62
Next: Bad-Pixel Methods
Up: Starlink Standard Data Structures
Previous: Errors

Starlink Standard Data Structures
Starlink General Paper 38
Malcolm J Currie, P T Wallace &
R F Warren-Smith
1989 January 20
E-mail:ussc@star.rl.ac.uk

Copyright © 2008 Science and Technology Facilities Council