The flexible and general-purpose character of the structures described in this document stems from their simplicity. This was a conscious design decision, the more traditional ``we've thought of everything'' approach having been rejected for reasons given earlier. By keeping the structures simple, it is possible to be reasonably precise about the processing rules, and this will enable users to mix applications from different packages in their processing schemes.
However, the standard structures do not immediately cater for package- or instrument-specific objects and their processing, and indeed show very little evidence of their planned astronomical rôle, which is realised through the use of extensions.
Extension information can be stored only in specially reserved places within certain standard data structures (including the NDF). These places comprise optional structures of NAME [MORE] TYPE EXT, which contain, in turn, the extensions proper, usually of TYPE EXT. The NAMEs and TYPEs of the extensions, self-contained assemblies of related information peculiar to an application package or data source, must be registered with the Starlink Head of Application to avoid clashes. (Which [MORE] they go in has also to be specified.) Programmers should select names which are sensible, descriptive and related to the extension and the project concerned. Simple generic names should be avoided in case they are needed later for Starlink general-purpose packages, e.g. [HEADERS], [PHOTOMETRY].
Starlink will, in due course, define standard representations
of time and celestial positions (using the rules
of Creating New
They will be implemented as extensions, not additions to the
standard structures. It has not yet been decided
whether applications in the KAPPA package
will process these standard extensions, or whether a
new package, of basic astronomy applications, will be written.
Starlink Standard Data Structures