In most of the ASPIC applications (see SG/1) such objects -- which have to be expressed in simple ways akin to FITS descriptors -- are simply ignored, and consequently do not appear in any new data frames created by the applications.
A hierarchical data system like HDS enables all these specialist data to be expressed in natural ways and to be attached to the main data structure at appropriate places within the structure. During processing these extension substructures can be copied to output data structures. Of course, as a result of the computations there may then be inconsistencies between the specialist and the general data objects; this is unavoidable. Rules will have to be laid down about what applications can be run on what types of data and in what order, and sometimes it may be necessary to resort to utilities which edit HDS structures to fix up inconsistencies. Specialist packages could implement all this transparently by providing command procedures.
In the NDF, extensibility is provided through the [MORE]
structure. Information required by application packages (and
under the complete control of those packages) is arranged
into structures usually of TYPE 
EXT
and stored within
[MORE].
In order to allow
applications to recognise their own extension objects
without risk of clashes, the
names and types of the extension structures
must be registered with the Head of Applications. An
example of an extension might be one called ASTROMETRY, which
would contain information about the relationship between
the data and the celestial reference frame.
[MORE] structures can occur once at the top level of the NDF, and once in each [AXIS] element.
As well as processing the extensions they recognise, applications are obliged to propagate all other extensions to any output structures.
Details of the defined extensions are given in other documents.
Starlink Standard Data Structures