[fitsbits] updates to the FITS standard document

[van Nieuwenhoven, Richard]

I completely concurre, the only thing I would suggest is to use the first 80 or 160 bytes of the first 2880 fitsblock to describe it. 

that way a very simple progema can be written to force backward compatibility if nessesary


  Ritchie
________________________________________
From: Erik Bray [embray at stsci.edu]
Sent: Monday, June 29, 2015 6:18 PM
To: van Nieuwenhoven, Richard
Subject: Re: [fitsbits] updates to the FITS standard document

Oh, trust me.  I've suggested multiple times the notion of versioning FITS and
adding an unambiguous way of listing features / conventions used within a
specific file.  In the past this has been met with glassy stares and insistence
that it is not necessary, or that there is really only one version of FITS (the
former is unhelpful, while the latter is downright dishonest).  If FITS had
these (in my mind very obvious) features most of this discussion about how to
extend and advance the FITS standard would be moot.  Supporting multiple
versions of the format in software is easy if you know what the differences are
between those versions.  I've had some in this group claim that that makes it
harder, but I can say as the maintainer of FITS software that having to guess
what is intended in any given FITS file is much, much harder.

At this point my preferred syntax for indicating that a file is "FITS 2" and not
backwards-compatible with old FITS is spelled:

#ASDF 0.1.0

http://asdf-standard.readthedocs.org/en/latest/

Erik

On 06/27/2015 12:55 AM, van Nieuwenhoven, Richard wrote:
> 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 ....
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>