[fitsbits] Proposed Changes to the FITS Standard

[Preben Grosbol]

On Monday 23 July 2007 21:03, William Pence wrote:
> Please post any comments, suggestions, or concerns regarding these
> proposals (or any other suggestions for improving the Standard document)
> here on the FITSBITS email list, or on the associated sci.astro.fits
> newsgroup.   Comments may also be submitted to any member of the FITS
> technical panel that produced these recommendations (listed below).

After some delays I finally had a chance to go through the changes to the 
FITS standard as proposed by the technical panel.

First of all my congratulations to the panel for its excellent work which has
produced much more consistent and readable standards document. During
my reading I did not come across any major issues but there are several
points which are important enough to raise.  Taking first section 1 of the
summary:

  4. Section 3.5  Deprecate 'special records'

      I think it's okay to deprecate 'special records' as the general
      extensions should be able to handle our future needs. In an
      age with computer virus, it may be safer to have some handle
      on what can be in a FITS file.

  5. Section 3.7  Restrictions on changes

      The argument is understandable but the implications very wide.
       It would allow dramatic changes such as redefinition of keywords.
       Something like this is needed but we may need to consider the
       best wording.

  7. Section 4.1.2.3  Repeat of keywords

      It may be too strong to forbid such repeats of keywords.  It should
      certainly be deprecated but it may place a significant load on many
      applications which just want to add some keywords to a header.
      They would be required to actually check if they would duplicate
      or not.  A deprecation and definition that the last value takes
      precedence may be more appropriate.

 11. Section 4.4.1.2  PCOUNT and GCOUNT

      In principle okay but one should check if this would require
      existing software to be changed.  There may still be legacy 
      tasks which write e.g. Random groups format.  The new
      section 3.7 would not work in that case.

 15. Section 4.4.3.1 Reference to specific extensions

      As there are many recommendations in the document, it would
      be good to retain a deprecation of explicit reference to other
      extensions.  The point is broken links if HDU's are moved.
      This opens the old issue on how to create a unique reference
      to any HDU.  It would be an advantage for some applications,
      such as in interferometry, where cross-references between binary
      table sometimes are used.

 17. Sections 7.2.2 and 7.3.2   TTYPEn

      The reason for avoiding '-' was the mapping of the TTYPEn names
       into variables is some languages.  It is irritating to have '-' in
       keywords for the same reason and most applications would just
       substitute them with '_'.  I would either retain the old wording or if
       '-' should be allow at the same point deprecate the usage of it.

 20. Section 7.2.5   Deprecate implicit decimal point

      We should check it with the data centers.  The reason for including
      such cases was to accommodate direct encoding of legacy tables
      which could have used such formats to save space (at the time
      when a punch cards was real and only had 80 columns).

Going through the actual text I noticed the following minor points:

 - It would be better to name Appendix A 'Formal Syntax of Keyword Records'
   to be in line with section 4.1

 - The font of COMMENT in section 4.1.2.2 seems wrong

 - It would look nicer to start the table with BITPIX 8 in table 4.9 and 7.7

 - Since the description of WCS keywords like CDELTn was moved to section
   8, it would be good to have a reference to that section in section 4.

 - It may be good to repeat a reference to fortran in the description of the
   TDISPn keyword in 7.2

As said before - my compliments to the panel
for very good work,
Preben