[fitswcs] WCS documents

[Eric Greisen]

Clive Page writes:
 > On Tue, 16 Oct 2001, Mark Calabretta wrote:
 > 
 > > "Once FITS always FITS" requires new FITS readers to parse old FITS files,
 > > not vice versa.  If the software can't (or won't) adapt then the language is
 > > dead in the same sense that COBOL is dead.
 > 
 > Yes, but I think there are two compatibility issues:
 > 
 > (1) It's important for existing files to work with updated software
 > (That's the "once FITS always FITS").
 > 
 > (2) It's also desirable that existing software should not crash when
 > presented with files written to the new standard, but should, if at all
 > possible, simply work without benefit of the new feature.
 > 
 > It's factor (1) which gives concern with the proposal to add [units]
 > strings to comments: it is possible that existing files have comment
 > strings including square brackets which will fool a new units-parser.  I
 > personally think this is fairly unlikely, and that the /[units] proposal
 > is on balance a good one.

     That is why the [] proposal appears in Paper I and even in the
Pence proposal as "recommended".  No parser should ever count on the
contents of an ordinary comment field, since no grammar was specified
20 years ago.

 > 
 > It's factor (2) which makes one worried about adding a new TFORMn or
 > TDISPn value (e.g. HMSw.d for sexagesimal formats) which would be the
 > obvious way of adding this feature.  An old program which only expects the
 > existing list of valid TDISPn values might fall over, because the current
 > Standard says "only the format codes shown in table 10 are permitted".

      Stupid programs will fall over, smart ones will know that they
do not know.  Smart ones are prepared to get improper FITS and
survive, albeit with complaints and lack of understanding.

      One could argue about whether anyone should be using sexagesimal
in a FITS table - will people want it as a keyword value next?  I
believe that the authors of the tables extension considered
sexagesimal and rejected it.  Angles should be put in floating (double
precision) degrees.  I can understand the use of sexagesimal to convey
old tabular data, however.  But I do not like adding new keywords for
a function that a current keyword really should perform.

 > If, on the other hand, the sexagesimal formatting option were to be
 > specified by an additional keyword such as TANGLn and a valid
TDISPn value

    Does this work?  Is the sexagesimal column actually 3 - 2 integers
and a float, or 1 consisting of a string of some specified length and
no obvious content to a computer (just to a reader)?

 > were also provided, then a file using the new convention would at least be
 > displayed in a usable way (though in decimal format rather than
 > sexagesimal) by old unreconstructed software.  On the other hand, there's
 > only a very short list of reserved FITS keywords, and who can say whether
 > someone somewhere hasn't already used TANGLn (or whatever else is chosen)
 > for some other purpose?  In my opinion, because of the way the current
 > Standard has been written, there's no obviously good upgrade path: we just
 > have to choose the one least likely to give problems in practice.

      I agree.  It is good to avoid obvious pitfalls to older, limited
software but we can kill ourselves avoiding trouble for old software
that was too inflexible to survive the occasional oddities written by
various software.  There is a well-known package that at times writes
the NAXISi keywords AFTER some optional keywords.  Now that is a hard
one to survive.

 > There are just one or two areas in the current FITS Standard where
 > extensibility is built in, for example you could write a file with
 > SIMPLE = "F"
 > and all bets are off (but that's not much help in practice).  And the
 > values of the TFORMn keyword are of the general form "rTa" where "a"
 > consists of additional characters which are optional and so far not
 > defined.  It's a pity, in my view, that a few more extensibility features
 > were not included in the Standard.

The original standard papers were criticized as "too hard" for the
times.  Extra extensibility clearly is there or the format would have
dies long ago - the tables extensions, WCS, etc are all extensions.
To have everyone agree on them is the hard part.

Eric Greisen