[fitsbits] structurally compliant FITS

[Lucio Chiappetti]

On Mon, 29 Jun 2015, Mark Calabretta wrote:

> Yep.  Describing parts of the standard as "optional" is not particularly 
> meaningful, nor helpful.  Specifically, I was responding to Lucio's 
> "conventions which are parts of the standard, while remaining optional".

>>> Ignoring INHERIT or CONTINUE potentially produces *wrong* answers 
>>> without providing even a hint that anything is wrong.  That's not what 
>>> I call "harmless".

About "optional" and "harmless".

I naively meant "optional part of the standard" as "if you need to do it 
do it this way, if you do not need it just don't do anything".

Otherwise said, most conventions define new RESERVED keyword, not new 
MANDATORY ones.

"harmless" combines with "optional" in the sense that I do not need a 
feature I won't support it, and will spot it with a warning message 
"unsupported". This is of course the case for homegrown adhoc software 
(which does not mean to be an all-purpose FITS reader). I had cases of my 
own software which read BINTABLES with a maximum number of columns. If the 
file had more, it failed with a warning "unsupported - too many columns" 
(corrective action, if I needed to process that file, was to edit a 
PARAMETER and recompile). Or I have a slim java image viewer which deals 
only with TAN WCS. If it encounters a ZPN WCS it issues a warning (it can 
display the image, but not convert pix<->sky).

CONTINUE may be a different case. You actually said correctly that it 
introduces a new datatype w.r.t. the "shorter" string. Or otherwise said, 
it breaks the equation of a "logical keyword" fitting in ONE card image 
(we had text in 4.1 about that in an earlier draft). Incidentally, since 
you asked, I've not yet thought how to deal with that in Fortran (or 
Java), but I did it in IDL and was rather easy (could give a link 
privately to those interested).