[fitsbits] Proposed Changes to the FITS Standard

On Fri 2007/08/17 13:18:40 -0400, William Pence wrote
in a message to: FITSBITS

For example, version 2.0 of the FITS Standard introduced a new
requirement that the value and comment fields in a keyword MUST be
separated by a slash character. I think the FITS community in general

Since it was once optional (which is news to me) it means, in principle,
that FITS header parsers always have to treat it as optional since they
can't know which set of rules was used in writing a FITS file.

The same applies to repeated keywords. Since it was once legal all you
can do retrospectively is to warn against the practice and say that the
interpretation is implementation-dependent (but I must again draw
attention to the concept of record-valued keywords proposed in WCS Paper
IV in which keywords may be repeated with different values and yet still
be individually interpretable).

It would be useful for the FITS 3.0 document to list inconsistencies in
syntax in an appendix, e.g. such as the requirement for a slash between
value and comment introduced at version 2.0.

In light of this I agree with Rob that versioning would be a good idea.
Perhaps the best way to introduce it would be to change the basic syntax
in such a way that it broke old readers, e.g. by removing the SIMPLE
card and replacing it with, say FITSVERS= 3.0.

Versioning would be used to flag the use of new features or new syntax.
Once FITS had versioning, a newer FITS reader (that knew about
versioning) would be able to

1) detect if a FITS file contained newer features/syntax of which it
was unaware and therefore could not handle. For example, a new
standard extension format would have a new version number
associated with it.

2) warn of deprecated/"illegal" usage in more recent files.

Newer FITS writers would still be able to write files according to the
features/syntax of older versions (including writing SIMPLE =) so that
they were interpretable by older readers.

Mark Calabretta