[fitsbits] XTENSION = 'FITS' proposal

[Steve Allen]

On Fri 2002-04-12T12:07:34 -0400, William Pence hath writ:
> One big advantage to using these GROUP_BEGIN and GROUP_END marker HDUs
> instead of a new XTENSION = 'FITS' HDU is that existing FITS software would
> still be able to access any of the HDUs within the file, even if it knows
> nothing about the grouping convention.

This is a nice scheme, and it resembles the MIME conventions for
creating text e-mail messages which can have arbitrarily deep
hierarchical structure of messages within messages.  But for MIME
e-mail it is a given that re-ordering of components is not sensible or
permissible.  The same sort of restriction on the handling of the FITS
file which forbits re-ordering of HDUs does not currently exist.

Indeed, the institution of such a scheme could be construed to be grim
given that NOST 100-2.0 section 4.4.3 says

    Standard extensions and other conforming extensions may appear in
    any order in a FITS file.

It is almost certainly the case that this means the standard does not
restrict the ordering, but some FITS application writers may have
taken it to mean that the standard does not restrict the re-ordering.
The meaning of the standard would need to be clarified for this scheme.

> [EXTNAME example omitted]

> This defines 2 hierarchical groups, each consisting of a base image and
> associated exposure maps and bad pixel lists, but in this case there is no
> restriction that the HDUs in the group be physically adjacent in the FITS
> file, or even co-located within the same file.

Again, this requires a restriction on manipulation of the content of
EXTNAME values, and a requirement of uniqueness for EXTNAME and
EXTVER within some domain.  The current standard is duly vague about
such things.  It is not clear how the standard could evolve to assert
such uniqueness requirements without creating a new keyword to handle
the function of being a domain-wide-unique EXTVER.

The interaction between the rubric "once FITS, always FITS" and the
evolution of FITS for such purposes is not widely understood.  Every
new part of the standard consumes some of the very limited 8-character
keyword namespace.  That and every new scheme of the sort given here
risks obsoleting some local convention and requiring rewrites of tools
that manipulate FITS files.

Who really understands the nature of the legislative compromises
between adding new capability and obsoleting old local standards?

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93