[fitswcs] WCS documents

[Clive Page]

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.

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".

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
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.

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.


-- 
Clive Page,
Dept of Physics & Astronomy,
University of Leicester,    Tel +44 116 252 3551
Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311