### 8 Extensions

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 Section 13). 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.