13 Creating new structures

 13.1 Definitions
 13.2 Algorithm
 13.3 Explanatory Notes
 13.4 Extensions

The methods presented in this section are intended to ensure that the rules given in Section 2 are adhered to. Particularly, it makes sure that standard structures are used wherever possible, and therefore encourages the building of new structures (when needed) by gathering together existing structures, so ensuring the maximum commonality.

New structures must not be constructed simply by adding new components into standard ones (which is illegal), but instead by adding a new layer. The HDS hierarchy then provides a natural barrier between separate structures, and ensures that further components can later be added at any level without risking naming conflicts.

13.1 Definitions

In the description of the design process the total hierarchy of structures is called a dataset to distinguish it from a single component structure. It is equivalent to the contents of an HDS container file. The term structure refers to a set of related data items; it corresponds to a single level of a dataset. Often a dataset will consist simply of a single structure.

13.2 Algorithm

A summary of the algorithm to be used when creating a new dataset is given below. The circled numbering refers to expanded notes in the next subsection.

Define what the software is going to do and not going to do   1

Identify, in concept, the datasets required

Determine their interrelations, perhaps via a tree diagram   2

Start at the most deeply nested level of the hierarchy

for each structure

Identify the data components  3

if an existing standard structure can be used then

Use it

Place remaining associated items in a new structure or in an extension


Assign a unique HDS TYPE to the new structure   4

Assign a NAME to each component   5

Determine the rules and restrictions governing the way the data will be stored in the

  various components

Assign a TYPE to each component   6

Identify the sorts of operation to be performed on the structure and ensure they are

  meaningfully defined   7

if the processing of a component cannot be defined in some cases then remove the

  component from the structure

Implement and document the software needed to process the new structure   8

if the new structure is to become a standard type then

Submit it and its software to Starlink for approval  9




13.3 Explanatory Notes


13.4 Extensions

Once a “core” of fairly simple standard structures exists, the process of designing more specialised structures will be devolved to the various SIGs, who can use the simpler structures as building blocks. This avoids the problems of the ‘all or nothing’ monolithic approach. When a more complex (and therefore highly specialised) structure is built out of simpler ones, software will then automatically exist for processing all its substructures in a more general way. This should give a high degree of flexibility.

There will be independent extensions, each having a uniquely defined TYPE together with rules for its interpretation. Though many extensions will be independent and self-contained, some will form hierarchies. The design of each extension should be kept straightforward and appropriate to the kind of software which will use it. Simple and specialised, simple and general, and complex and specialised are all acceptable, but implementors should beware of attempting to design extensions which are both complex and general. By introducing a strict criterion to decide whether a given component is acceptable (“do we know how to process it?”), it is ensured that the problem is broken into manageable pieces, the complexity of which does not exceed our software-writing abilities.