### 1 Introduction

This document should be read by programmers wishing to write applications software for Starlink. It describes various standard ways of arranging data, using the Hierarchical Data System (HDS). The most important of these is the NDF (Extensible $n$-Dimensional-Data Format), which is suitable for expressing a wide variety of data which occur in $n$-dimensional arrays—for example pictures, spectra and time series.

The early part of the document deals mainly with concepts, while later sections give more detailed definitions of the data structures.

Standard data structures comprise an important part of the software environment. Their use enables software packages to share data, thereby reducing the number of functions which must be duplicated and hence the total quantity of software needed.

To assist in designing standard data formats of adequate versatility, Starlink has implemented HDS, the Hierarchical Data System, a flexible system for storing and retrieving data in a structured fashion. HDS structures consist of assemblies of data objects arranged in trees. Each tree resides within a container file, one top-level tree per container file. Data objects have a NAME, which identifies that particular object, and a TYPE, which describes what sort of object it is. A data object can either be a structure or a primitive. Primitives are such things as integers, character strings, and floating-point numbers, and express the data themselves. Both structures and primitives can either be single items or multi-dimensional arrays. The overall philosophy is analogous to a computer’s file system, where the files themselves (the equivalent of HDS primitives) are embedded within a hierarchy of directories (the equivalent of HDS structures).

Most people find the “tree” picture the most natural when visualising HDS objects. However, on some occasions it can be useful to regard an HDS object as a box (or $n$-dimensional array of boxes), marked with a NAME (unique at that level) and a TYPE (giving a clue to what might lie within). When the box is opened, further boxes are found. Eventually, you get to the items themselves (the primitives); all the rest is packaging.

Readers of the present document should be familiar with the HDS Programmer’s Guide, SUN/92.

In conjunction with a release of the Starlink Software Environment (SSE—a forerunner of the ADAM system), Wright & Giddings (1983) proposed a number of standard data structures using HDS. The discussions which followed raised many new difficulties, and the proposals were never ratified. However, in the absence of anything more definitive, the proposed standard structures were used by several groups of implementors. During 1987 the discussion was re-opened following the selection of ADAM as the Starlink environment. The electronic correspondence on this topic runs into several hundred messages filling three bulky folders. It has not been easy to produce a design which will please everyone, for reasons that will be dealt with in the next section.