[fitsbits] structurally compliant FITS

[Erik Bray]

On 06/29/2015 03:56 AM, Mark Calabretta wrote:
> On Fri, 26 Jun 2015 14:06:10 -0700
> Rob Seaman <seaman at noao.edu> wrote:
>
> Hi Rob,
>
>> I suppose you are suggesting that since pretty much everything is
>> optional after the first 2880-byte record that we might omit the word
>> optional for more particular cases throughout the standard?
>
> 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".
>>
>> In previous cases of modifying the standard we have jiggered things
>> such that new-format files might either be invisible to unmodified
>> software (e.g., relying on the extra appended record gimmick), or
>> rather would cause unmodified software to abort (e.g., negative
>> BITPIX values).
>>
>> But several of the conventions are already perfectly legal FITS.  And
>> projects already use INHERIT, for instance.  Improving the
>> documentation and hooks for recognizing such usage will be surely
>> "less harmful", if not "harmless", right?
>
> Again, I was only responding to the statement, made repeatedly in
> various ways by several people, that INHERIT may be "ignored" and doing
> so is "harmless".

It depends--you're certainly right, as you've made clear, that ignoring INHERIT 
if it's used for WCS keywords is potentially harmful.  But for informational 
metadata ignoring it is pretty harmless.  In any case, I don't know whether or 
not any HST data uses in the former way, but given that most if not all generic 
FITS readers ignore the INHERIT keyword the practical harm would have been 
apparent by now, I think?

That doesn't make the potential for harm any less real.  And I already wrote 
that if INHERIT were added to the standard then ignoring it *would* be harmful. 
  But the only way it's been used in the past is as a hint to software for 
specific data models--if a keyword isn't found in an extension header, maybe it 
can be found in the primary header.

> As you suggest, inheritance would better be implemented in such a way
> that ignoring it causes an error.  However, that would probably require
> creating new syntax, and that's not something that conventions can do.

Sounds more and more like this is best left out of the standard then.  If 
anything I would add an admonition that conventions that try to implement a 
specific hierarchical data model on the standard are best left as local (but 
documented, please) conventions :)

Erik