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

On Fri 2007/03/23 16:06:53 EDT, William Pence wrote
in a message to: FITSBITS

A document describing this convention and a sample FITS file that uses
it are available for public review and comment from the FITS registry
web page at

http://fits.gsfc.nasa.gov/fits_registry.html

My comments only refer to the documentation of the convention, not the
convention itself.

The document states:

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

Also, while recommended usage may assist human interpretation, it is
unhelpful for software which can't assume that any recommendations have
been followed and so must be completely general.

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

"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? A simple way to picture keyword
inheritance is to think of appending the extension header onto the
primary header (as a character array) and feeding the lot into a header
parser that accepts the last occurrence of any repeated keyword.

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

General:

The FITS WCS standard defines default values for WCS keywords that are
omitted from a header. The document should discuss how the INHERIT
convention interacts with the omission of such keywords.

Although it is reasonable to discuss the relative merits and
deficiencies of the convention compared to other alternatives, much of
the content of the first paragraph of the section entitled "Practical
Considerations" seems to deal with one particular implementation. As
such it should either be omitted or recast into a discussion of the way
that it should be implemented.

As another practical consideration, serial readers (e.g. tape or
internet download) have no way of knowing in advance whether the primary
header will be required for later use by an extension that inherits it.
Therefore, in order to implement this convention, they would need to
cache the primary header from ANY general FITS file in case it later
turns out to use the INHERIT convention.

Mark Calabretta
ATNF

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.

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