[fitsbits] Bintable proposals

[William Pence]

Mark Calabretta wrote:
> 
> Anyway, NAXIS2 = -1 is essentially for our own internal use.  However, if
> anyone else wants to adopt the ideas then I would advocate that they used
> the same syntax and semantics. 

Hi Mark,

There are 2 issues here:

1.  Is it OK to generate pseudo FITS files in exceptional cases where it is
not practical to conform completely to the FITS Standard?

2.  Should the FITS Standard be modified to recognize these pseudo FITS
files as legitimate FITS files?

The answer to 1 is clearly yes;  internal data products can be stored in any
format.   I would say the answer to 2 is 'no', however, unless there is a
very compelling case to do so.  In the case you cite, wouldn't it be much
simpler to fix the files by substituting the correct value for NAXIS2 at the
time the original file on tape is copied to another tape or to disk for
distribution to general users?  This seems like a much simpler solution than
modifying the standard and all existing FITS readers to support files with
NAXIS2 = -1.

It may be opening a can of worms to even bring this up, but there are many
other requirements in the FITS Standard that seem rather artificial and
could probably be relaxed with little or no effect on users and applications
programs that read the files.  Some examples are:

- last block in the FITS file must be padded to a length of 2880 bytes
- fill bytes at end of ASCII tables must be ASCII blanks
- fill bytes at the end of binary tables must = 0
- fill bits in bit ('X') columns must = 0
- mandatory keywords must be in fixed format (e.g., the value of 
  NAXIS must be in column 30)
- lowercase letters are not allowed in keyword names
- END keyword must be blank in columns 9 - 80 (no comment allowed).
- primary header must have an EXTEND keyword if there are extensions
- EXTNAME, EXTVER, and EXTLEVEL keywords not allowed in primary header
- no leading spaces allowed in the value of the XTENSION, TFORMn, TDISPn,
  or TDIMn keywords. 

Many FITS readers already effectively ignore some of these restrictions. 
One could go even further and relax the most often cited limitation in FITS
that keyword names be limited to 8 characters.  One could remove the length
restriction altogether (but still within the constraints of the 80-character
keyword record), or perhaps it would be sufficient, and more palatable to
some, to just double the allowed keyword length to 16 characters by
permitting the equals sign and space characters that separate the keyword
name and the value to be in columns 17 - 18 instead of only in 9 - 10. 
(Technically, this does not violate the FITS Standard, but current FITS
readers do not recognize the semantics).  Such a change would have a
non-trivial impact on applications programs, many of which would need to be
modified to support the longer keywords, but I think it would be well worth
the effort in the long run.

-Bill Pence
-- 
____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)