[fitsbits] Start of the 'INHERIT' Public Comment Period

[Rob Seaman]

Bob says:

> I have to express some concern about registering the INHERIT  
> convention.
> The documentation notes a number of potential problems that can occur
> when FITS software that is unaware of the convention is used to read,
> interpret, and write new copies of files that use INHERIT.

1) Isn't the notion of the convention registry to record what is already
being used around the FITS community?  NOAO relies on INHERIT
for our MEF data from the MOSAIC DHS and will rely on it for the
NEWFIRM DHS.  The NOAO Pipeline understands INHERIT.
The convention has served us well.

2) NOT documenting INHERIT certainly won't help the community.

3) IRAF has understood INHERIT for three-score-and-ten dog years.

> It would be cleaner, I think, to define more clearly the rules for  
> how primary
> headers pertain to extension headers (e.g., the concept of inheritance
> applies by default, or whatever).

4) Yes, but that boat has sailed.  The community has been on a course to
deal with inheritance since this note from the image extension paper:

	"Although allowed, it is recommended that the primary header does
not set the keyword NAXIS=0, since it would not make sense to extend a
non-existing image with another image."

FITS is either going to tie the contents of separate HDUs together
semantically or not.  The community eagerly - and widely - adopted the
notion of the primacy of the primary HDU - likely before the words above
were published.  Implicit here is that the primary header of an empty
HDU is often used for information that applies to the entire file.

5) If not INHERIT, then what?

6) And we'd still be left with gazillions of files that rely on this  
convention
as an organizing semantic principle.  Clearly the first step in  
revisiting the
fundamental semantics of a FITS file (of which keyword inheritance is  
only
a small part) would be to protect our investment in previous data  
products
by documenting the current de facto standards.

6a) In any event, the first step in deprecating any convention would be
to recognize its existence.

> This is something we might recommend to the recently formed FITS  
> review
> panel to discuss.

7) By all means, but only in an advisory capacity.  I presume we're  
not thinking
of changing the fundamental FITS standards process?  It has served us  
well
for many years.

8) Really - isn't documenting the current usage the simplest thing to  
do?
All of these conventions are conventional, rather than standard,  
precisely
because they reflect issues that were thorny to deal with the first  
time around.
Few will fall into the same category as the checksum keywords - i.e.,
pre-existing legal FITS usage demanding no clarification of the  
standard.

Rob