[fitsbits] Proposed Changes to the FITS Standard

Rob Seaman seaman at noao.edu
Tue Jul 24 14:21:44 EDT 2007


> Please post any comments, suggestions, or concerns regarding these
> proposals (or any other suggestions for improving the Standard  
> document)

Good job.  Time well spent.  Thanks to all involved.

Comments indexed to the summary:

1.4)  Extensions ARE special records from the point of view of  
classic FITS readers.  Rather than deprecating or attempting to ban  
them, perhaps just explicitly state that new uses for special records  
require IAUFWG approval.  (But see 1.10 below.)

1.5)  Unenforceable in the absence of some explicit mechanism tagged  
to the DATE keyword (for instance).  On the other hand, such a  
mechanism would be equivalent to explicitly versioning each file.   
This would be a change to the basic philosophy of FITS.  I think of  
opening old Word files with new editions of MS Office - or worse -  
trying to do the reverse.

1.6)  Harmless, but also unenforceable.  Not just an attempted  
constraint on software, but also on humans editing headers manually  
using IRAF hedit, for instance.

1.7)  No, but there are many headers that unintentionally repeat  
keywords.  They should not therefore be rendered unconforming FITS.

1.9)  Few users will choose 64 bits when 16 will do.  Those that do  
may well have a good reason.

1.10)  This is a requirement placed by the IAU, not FITS per se.   
Might such policies better be concentrated in a common section?  On  
the other hand, it is eminently practical to manipulate unknown but  
conforming extensions.  In particular, software we write today can  
skip and list and otherwise manhandle conforming extensions from  
tomorrow.

3.1)  Italicizing these words may be distracting.  Must it be done?   
I should not recommend it.  Shall it be optional?

In general, as with the previous comment about the EXTEND keyword, we  
should be careful what we attempt to require regarding new data since  
it may place unfunded mandates on old software.  Deprecation of a  
feature is not equivalent to requiring its converse.

A couple of other general comments:

Any chance of blessing checksums on this go-around?  Then we could  
fret about using "one's-complement" versus "one's complement", too.

There is a very real possibility that UTC will be turned into  
something other than a flavor of Universal Time, i.e., other than an  
approximation to Greenwich Mean Time.  Perhaps we should consider how  
best to deal with such a situation.  A generic "UT"?  Use raw UT1?   
Define a UTA (Astronomical) retaining IAU mediated leap seconds?   
This is a broader issue than FITS, but we would have to start somewhere.

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20070724/9d6abdb4/attachment.html>


More information about the fitsbits mailing list