Subject: Comments by R. Hanisch (St Sci)

From: [email-masked]
Date: Mon, 9 Oct 89 16:51:33 EDT

******************************************************************
              The following was sent to NRAO by R. Hanisch
               ([email-masked] or [email-masked])
   ******************************************************************

From:   STSCIC::HANISCH       5-OCT-1989 17:50:34.74
To:     STOBIE
CC:
Subj:   current version of FITS memo

                Some Comments About Single-Dish FITS Format
                        and Related FITS Issues

                          Bob Hanisch, ST ScI
                              October 1989

  In preparation for the meeting in Green Bank later this month, I have
written down some ideas concerning how to handle the special case of single
dish radio astronomy data within the FITS format.  This is being distributed
in advance of the meeting so that attendees can think about the issues prior
to arrival.

  Harvey Liszt distributed an e-mail message to all of us which contained a
careful analysis of the header structures proposed by Stobie and Morgan.
Unfortunately I think this analysis does not really address the general
problem, i.e., how to manage the keyword space unique to a certain class of
instruments, detectors, or a particular project.  From the FITS point of view
this is the critical issue, and most of the items discussed in the memo are the
details that need to be worked out once the more general problem has been
addressed.

  What Stobie and Morgan described in their original memo is a simple
hierarchical keyword space.  The presence of the hierarchy is denoted by the
use of the SINGLDSH keyword, followed by a secondary hierarchy (GENERAL,
NRAO-12M, etc.) which further defines the scope of the keyword definitions.
The AIPS system has already implemented a hierarchical scheme of sorts, in
that AIPS uses the FITS COMMENT and HISTORY records for storing information
unique to AIPS.  Non-AIPS FITS readers have no obligation to parse the
contents of these cards beyond simply recording them with the other header
information, or even ignoring them if they wish.  The point here is to have a
keyword space which can be hidden from FITS reading programs that do not
understand or have no interest in some specialized set of keywords.  The
advantages of such a scheme include the fact that we need not have any
community-wide consensus on the definitions of ALL FITS keywords.  Rather,
subgroups such as the single-dish radio astronomy community can agree upon
their own conventions and be largely independent of other subdisciplines.

  If we agree that having some sort of hierarchical keyword naming scheme is
worthwhile (and I think that this is NOT a foregone conclusion -- more comments
on this later), the first thing to do is determine the best syntax for its
implementation.  I see several difficulties with the proposal of Stobie and
Margon (and implicitly with the AIPS technique of hiding similar information
behind COMMENT and HISTORY records):

o  The proposal is limited to a two-level hierarchy, a primary domain (SINGLDSH)
and a secondary domain (GENERAL, NRAO-12M, etc.).  This seems unnecessarily
restrictive, although it is clearly simple to generalize to several more levels.

o  The keyword hierarchy takes up a lot of space on the header line, leaving
little space for values or comments.  This situation is exacerbated if deeper
hierarchies are to be permitted.

o  FITS readers require special code to parse the header and retrieve the
data values.

o  Everytime a new domain is introduced, FITS readers everywhere will have to
be updated to recognize (and most often ignore) the new domain name.

  Some time ago I proposed implementing hierarchical keywords by REQUIRING that
each hierarchical declaration actually begin with the keyword HIERARCH (this was
during a FITS planning meeting held in Charlottesville in Jan. 1988, as I
recall).  The reasoning was that this is such an ugly keyword that no one else
in their right mind would use it, thus it would serve as a flag to indicate
that a special parser would have to go into action in order to retrieve the
actual keyword name and value buried further to the right on the card.  In
retrospect, this plan suffers the same disadvantages mentioned above EXCEPT for
the last one; by reserving a special keyword to introduce a hierarchical
keyword domain, the problem of the arbitrary introduction of new domains is
circumvented. However, the other problems, especially the lack of space on the
header card, are not resolved.

  An alternative scheme has come to mind (based on an idea proposed by Doug
Tody at the same meeting) which looks much more like simple nested do-loops in
Fortran, or structure definition statements in any modern computer language.
It would be based on begin/end statements for various keyword domains, and
could be nested arbitrarily deep, accommodating things like
SINGLDSH/GENERAL/NRAO/12METER/... or whatever.  I propose to use keywords of
the form KHBEGIN and KHEND to signify a keyword domain (KH = keyword hierarchy;
I don't really care what the particular names are so long as we can agree on
something unique and representative).  For example, the syntax might be
something like this (paying little attention to the actual column spacing):