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

[Lucio Chiappetti's NoSpam Newsreading account]

On Thu, 12 Apr 2007, Mark Calabretta wrote:

>  "It is recommended that this inherit convention be used only in
>   FITS files that have a null primary array (e.g., with NAXIS = 0) to
>   avoid possible confusion if array-specific keywords  (e.g., BSCALE
>   and BZERO) were to be inherited."
> 
> If this is the way that INHERIT has always been used then it should be
> required, not "recommended" (inheriting from a non-null primary HDU
> would be asking for trouble, especially concerning WCS keywrds).

1) I doubt the authors of a convention (which, once again, is NOT a 
   standard) can "require" anything. The convention is all just a
   recommendation, or even less, a suggestion.

2) WCS keywords could/should be considered "array specific keywords" 


>  "If the INHERIT keyword is not present, nothing should be inferred about
>   whether the inherit convention should apply or not because the FITS
>   standard says nothing regarding the relationship of keywords in the
>   primary header to those in an extension."
> 
> This statement is contentious.  It is widely understood that FITS HDUs
> must be self-contained, whether or not that is stated explicitly in the
> standard.  Basically this statement tries to excuse the exploitation of
> a loophole in the standard.

Here I agree. The sentence does not belong to the convention. One of the 
purposes of convention documentation should be to allow the user/reader 
to identify a file as respecting a particular convention, ideally in an 
univocal manner. Then, IF the file is univocally identified as obeying a 
convention, and the reader supports it, it shall interpret the file 
according to the convention. If the reader does not support it, it 
interprets it as a "plain"file. If the file is not identified as obeying 
a convention, ditto.

About self-containment, it seems to me similar e.g. to the requirement 
of page independence in postscript (which is good practice but can be 
and is violated sometimes). Should the STANDARD say something about this 
(food for IAUFWG or the IAUFWG Technical Panel).


>  "When an application reads an extension header with INHERIT = T, it
>   should merge the keywords in the current extension with the primary
>   header keywords, ..."
> 
> What does "merge" mean here?  

E.g. creating a data structure with the keywords in the current 
extension, another with the keywords in the PHDU, and appending to the 
current one the kwds in the PHDU which are not overridden in the 
current. Sort of when configuration files in /etc, /usr/share, 
/usr/local and ~user are combined.


>  "... with the exclusion of the mandatory keywords, and any COMMENT,
>   HISTORY, and blank keywords in the primary header."
> 
> If COMMENT and HISTORY keywords are not propagated then there should
> also be some statement that extension headers must contain a full
> complement of COMMENT and HISTORY cards whether or not they duplicate
> those in the primary header.

Commentary keywords are intended as human readable documentation, not 
for computer processing. So they'd appear only once.

For the rest it seems normal sound practice for me to report in the PHDU 
computer-readable (keywords) information relevant to all extensions, 
e.g. the instrument configuration of the observation. Of course each 
extension should contain its own necessary data (so "array related" 
might include not only NAXIS* BSCALE WCS but also e.g TFIELDS and TT* 
keyowrds).

If a file contains, say, n image extensions which are respectively 
512x512, 512x1024 and 512x768, it seems silly (and incorrect) to me have 
NAXIS1=512 only in the PHDU.

If a file contains n binary tables, each with 5 columns but with names 
and types different, it is also silly to have TFIELDS=5 only in the 
PHDU (which, BTW, is not a binary table)

If a file contains n binary tables with different number of columns, 
but one of them (say the second) is always the same, it is equally silly 
having TTYPE2='energy' only in the PHDU.

-- 
----------------------------------------------------------------------
nospam at mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.