[fitsbits] updates to the FITS standard document

[van Nieuwenhoven, Richard]

Reading through all those reactions, as more or less a bystander in the
discussions, I get a rather radical idea... In software development I
have seen many standards come, go and evolve, and my feeling is that the
current proposal (as Tom summarized beautifully) includes many deep
changes to the standard. (Depending on the readers point of view)

The major thing currently missing in the standard is the knowledge if a
certain reader in a certain version understands a fits file of an other
certain version, and if the reader supports a certain extension of the
standard.

This will mail probably earn me a lot of "angry" reactions, but please
think about it before saying no.

Now to my proposal, lets break all the old fits readers out there! By
creating a new special first 80 characters of a fits file that will
break almost every reader existing. Lets say something like this:

"FITSFORMAT;2.1;INHERIT-CONTINUE-TILES-COMPRESSION-FEATURE_X"

And write following rules in the standard:

1. A reader may not read the fits file without a "force" option when the
software was developed at a time the major version part (the "2") did
not exist yet or does not support the major version part of the standard.

2. A reader may not read the fits file without a "force" option when it
does not know one of the extensions specified in the list. (the minus
separated list of used extensions in the fits file.

3. A reader should report in case of a version problem a detailed
description of what is not supported.

4. A force option should be provided to overrule, any incompatibilities.
But the user must be notified by std-error or other log means about the
possible incompatibilities.

This is just an example, you will probably have a better idea how to
pack this information. (And to break old readers)

By using the first 80 char's for this information, it is easy to remove
it from a file (move the second 80 char's to the first and make the
second blank). That's more or less a force option for all the software
currently existing.

The big advantage of such a approach (used in different colours in many
standards), is that future changes to the standard are much much easier
...

Now you can kill the messager ....