[fitsbits] Proposed Changes to the FITS Standard

[Mark Calabretta]

On Tue 2007/08/21 17:56:49 -0400, William Pence wrote
in a message to: FITSBITS <fitsbits at nrao.edu>

>The difference here is that I was quoting the revised definition in the 
>new draft standard, which doesn't allow for the possibility that EXTEND 
>= F.  Given that there are existing FITS files with EXTEND = F, the 
>definition should probably be revised to at least not prohibit this usage.

The text describing EXTEND was moved from one section to another (old
text in red on p34, new in blue on p36) so it is not immediately clear
in differences.pdf that this change was made in FITS 3.0 nor does
summary.pdf mention it explicitly.  (BTW, EXTEND does not appear in the
index.)

In answer to Steve's question, FITS is permissive in the sense that
anything that is not disallowed is allowed so

  Anything ever explicitly allowed can never be disallowed

and

  Anything not explicitly disallowed must always remain allowed

say the same thing, i.e. what was once allowed can never be disallowed.

There are two sides to the FITS 3.0 spec:

  1) How it is used by writers.  In this respect it may make sense to
     deprecate some usage (e.g. the ill-defined CROTAn, or EXTEND=F,
     or EXTEND itself) typically because it's replaced by a better
     alternative (e.g. PCi_ja) or is now considered redundant (e.g.
     EXTEND).

     However deprecated usage must remain legal because
     
     a) FITS 2.0 & 1.0 writers might not have been updated to FITS 3.0
        (and may never be) so will carry on using it,
     
     b) FITS 3.0 writers may want to help FITS 2.0 & 1.0 readers, which
        is why existing usage should not be deprecated without good
        reason.

  2) How it is used by readers.  In this respect what was once allowed
     can never be be disallowed.  If the EXTEND keyword was to be
     deprecated (it can't be disallowed) then a FITS 3.0 reader should
     not expect to find it, but it if did it should know what to do with
     it.
     
     In order to be complete and self-contained the FITS 3.0 spec must
     make it clear what was allowed in FITS 2.0 and 1.0 (e.g. EXTEND=F)
     because a generic reader that conforms to the FITS 3.0 spec may
     have to parse a FITS 2.0 or 1.0 file.

     Likewise, the FITS 2.0 spec should have stated explicitly that it
     had deprecated keyrecord comments without a "/" delimiter.

In concrete terms, if FITS 3.0 attempted to invalidate EXTEND=F without
warning that it was valid in FITS 2.0 then a new parser written in
conformance with FITS 3.0 would incorrectly conclude that files written
with EXTEND=F in conformance with FITS 2.0 were invalid.  The effect on
their operation would be implementation-dependent.

Mark Calabretta