Comments on NOST 100-1.2 of 1998-04-06

[Preben Grosbol]

Dear FITS exploder,
 I had unfortunately not time to read the NOST 100-1.2 document of
1998-04-06 carefully before due to other deadlines but here are
my first basic set of comments.  Due to travels, I would not
be able to discuss issues before 1998-07-21.  First a few basic
comments:

 1) In the e-mail announcing the review, it is stated that 'It will
    be submitted to IAU Commission 5 for formal acceptance ...'.
    This would not be possible with the current rules under which
    the IAU FITS Working Group only would consider proposals after
    they have been recommended by the three regional FITS groups.
    Thus, it would be natural for the NASA Technical Panel to
    submit their proposal to the North American FITS group for
    recommendation.  Having said that, I fully support that
    general comments are solicited through WWW to ensure a
    thorough review.

 2) One of the most basic rules of FITS is that not change should
    be made which would make current FITS files invalid.  As the
    proposals prohibit usage which is not explicitly illegal now, it
    is not acceptable in its current form.  One should distinguish
    two cases: a) changes which make old FITS files invalid, and
    b) modifications which make new FITS files incompatible with
    old readers.  Whereas the former changes must not be allowed,
    the latter should be avoided since they just add work for
    re-programming with little advantage.

I would like to complement the NASA FITS panel for an important
work which will benefit the FITS community greatly.  My concerns
are related to the details and not the general scope of the
document.

Below I have listed my explicit comments which are not complete
due to time pressure.

Best regards,
Preben Grosbol
ESO.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The explicit comments are given with reference to page (p) and
section (s) in the NOST 100-1.2 PostScript version of 1998-04-06:

p11,s4.3: 'The primary header may, but need not be, followed ... array.'

     A header is always followed by a data array.  The data array
     may, however, be of zero size.

p13,s4.4.3: '(or random groups records if present)'

     Formally the random groups records are special records and can
     therefore NOT be followed by an extension.

p15,s5.1.2.1: 'For indexed keywords with a single ...'

     This phrase tries to distinguish single index (e.g. NAXIS123)
     and multiple index (e.g. PC012015) keywords but as the latter
     is not clearly defined none of them are.  It must be reworded
     to make sense.

p15,s5.1.2.2: 'that field may be a null field'

     The concept of 'null field' is not trivial since multiple
     occurrence of the same keywords is not defined.  The problem
     arises since the type of the keyword is defined by its value.
     If a 'null field' is given first and the same keywords is
     later assigned a value the resulting type is unclear.
     The whole issue surrounding repeated assignment of keyword
     values should be resolved.

p16,s5.2.1: '... followed by a closing single quote ...'

     The FITS standard specifies that the closing quote first may
     occur in column 20.  Removing this restriction may cause
     significant problem for old readers without any added
     functionality.

p17,s5.2.3: 'An integer consists of a leading '+' or '-' ...'

     For positive integers there may be no leading '+'.

p17,s5.2.4: 'If only the integer part is present, the decimal point
             may be omitted'

    The FITS standard specifies that the 'decimal point' must appear.

p17,s5.2.5: 'enclosed in parentheses'

    The FITS standard does not specify the complex numbers must
    be enclosed in parentheses.

p18,s5.3: 'degrees are the required units for celestial ...'

   Although I agree in principle the wording is unclear e.g.
   some observatories are known to use keywords RA and DEC
   for the celestial coordinates and given them as strings.
   Should such files be defined invalid by this proposal?

p19,s5.4.1.1: 'SIMPLE ... is not permitted in extension headers'

   This is an additional requirement which may render existing
   FITS files invalid.

p19,s5.4.1.1: 'SIMPLE ... this standard in some significant way'

   Should be reworded as a FITS either conforms to the standard
   or not - 'some significant way' is subjective.

p19,s5.4.1.1: 'NAXISn ... and for no other values of n'

   Yes but again it is not specified in the FITS standard.  It
   would be better just to ignore such keywords.

p21,s5.4.1.1: 'XTENSION ... must not appear in the primary header'

   This restriction is not in the FITS standard and may render
   old FITS files invalid.

p29,s7: 'outside this field ... random groups format'

   Subjective statement which should be omitted.

p33,s8.1: 'TABLE '

   The string must include 8 characters i.e. 'TABLE   '

p33,s8.1.1: 'XTENSION ... 'TABLE ''

   The string must include 8 characters i.e. 'TABLE   '

p36,s8.1.5: 'ANSI FORTRAN-77'

   The reference to FORTRAN-77 should be consistent - either
   one should ANSI all places or none.

p37,s8.1.5: 'It may be stored, left justified, ... information.'

   The sentence is either trivial or should be rephrased to give
   some significant meaning.

p37,s8.1.5: 'The value of ...'

   It seems dangerous to reword the FORTRAN-77 format definition.
   Although it may be nice for a trivial implementation there may
   be slight differences in the interpretation if it is not a verbatim
   reproduction of the real standard.

p38,s8.2: 'IMAGE '

   The extension name is 'IMAGE   ' including three spaces.

p38,s8.2.1: 'XTENSION ... IMAGE'

   The string for the image extension is 'IMAGE   '.

p39,s8.2.1: 'NAXISn ... for no other values of n'

   An additional requirement which may render old FITS files invalid.

p46,s8.3.3.1: 'Array Descriptor ... of not more than one pair ...'

   As the field is 8 byte, it is exactly one pair and not zero.

p46,s8.3.4: 'Display Format'

   Again it is dangerous to rephrase the FORTRAN-90 format definition.

p46,s8.3.4: 'Integer data are encoded ...'

   It is not clear what is done with X and B type fields.

p47,s8.3.4: 'For data of type integer, logical ...'

   A reference to X and B type data should be made.

p51,sA: 'The following notation ...'

   It would be simpler if a more standard BNF was used.

p69,sE: 

   The points 8, 12, 15, 16, 18a, 19b, 29, 30d, 31b, 31c, 32, 33b, 37
   and 38 give cause to significant concern as they may yield
   incompatibilities with the FITS format.

p73,sE: 'applies applies' -> 'applies'

p76,sE: 'BIMTABLE' -> 'BINTABLE'