[fitsbits] Five FITS Proposals

[Rob Seaman]

On Oct 25, 2013, at 6:51 AM, Erik Bray <embray at stsci.edu> wrote:

> On 10/25/2013 03:56 AM, Peter Weilbacher wrote:
>> On Wed, 23 Oct 2013, William Pence wrote:
>>> 4.  Introduce a new FITS version keyword
>> 
>> This was one of the Thomas et al. suggestions at the BoF, but I didn't
>> really get the point. How does it help older FITS readers if a FITSVERS
>> keyword is there which they don't understand?
> 
> To me, this is the most important of the proposed changes, if anything in FITS 
> is changed at all.  This should be a prerequisite to any future changes.
> …
> For example, if a header uses CONTINUE cards there *must* be an indicator in the 
> header like
> 
> FITSVERS= '     3.1'
> FITSCV1 = 'CONTINUE 2007-07-11'

Many of the conventions already have compliance and versioning keywords, e.g., for tile compression ZIMAGE indicates compliance and the ZCMPTYPE and other algorithm keywords implicitly (and I’d say better) provide versioning.  If ZCMPTYPE is GZIP_2 and your code doesn’t know what that means then it should do exactly the same thing (exit with an error message, for instance) as reading a ZVERSION keyword and interpreting the implications of 2.3 versus 2.2.  This is better since most 2.3 compliant files will use the default Rice compression that did not change with that version transition.  (Or maybe it was 2.1 -> 2.2 that GZIP_2 was introduced - the point is precisely that I only care if I’m relying on that particular feature.)

For the checksum convention we discussed a CHECKVER keyword and it was omitted with the understanding that it would be introduced should it ever be needed.  It hasn’t been in close to 20 years.  And the nature of a 1’s-complement checksum is sufficiently different from a message digest, for instance, that should support for SHA-X or some (NSA not approved :-) alternative be added that this would likely now be a completely different keyword.  A file or HDU might quite reasonably use both old and new versions of some related conventions; how would the version keyword(s) indicate this?

Also, how precisely would versions be used on the battlefield?  Would a particular FITS library or application simply object to a file (as being too old or too new) and exit?  This is just going to lead to users editing the version keyword to claim compliance.  (Like manually editing a Postscript BoundingBox.)  The nature of FITS is that the standard is implemented in most cases on a per-HDU basis. Would it now be illegal to create a file mixing extensions adhering to different versions of FITS?  What does that even mean when a binary table and an image extension can adhere separately to conventions/sections of the base standard that word penned many years apart?

Which is to say that all libraries and applications should be compliant with the base standard.  And if versioning is needed for a registered convention it should be in that document.  In cases in which the base standard changes significantly enough to require community assets to evolve (i.e., archive holdings and observatory procedures, etc, not just third party software), then we will have to coordinate activities anyway as with Y2K, and I would hope that old data will always be regarded as remaining compliant.

Rob