[fitsbits] XTENSION = 'FITS' proposal

[Perry Greenfield]

William Pence writes:

> In fact it would probably require only a small change to the CFITSIO
library
> for it to recognize XTENSION = 'FITS' as a special case and then ignore
the
> NAXIS and NAXIS1 values and proceed as if NAXIS = 0.  This then would
> provide sequential access to all the HDUs within the groups.  One would
also
> have to permit extensions beginning with "SIMPLE = T" instead of XTENSION
=
> 'IMAGE'.
>
> However, this effectively becomes  identical to the GROUP_BEGIN and
> GROUP_END alternative proposal.  The XTENSION = 'FITS' extension serves
> exactly the same role as the GROUP_BEGIN extension. "Group" keywords (that
> apply to all members of the group) could be written in either case.  The
> only difference is that in one case the length of the group is given by
the
> NAXIS1 keyword in the 'FITS' extension, and in the other case the end of
the
> group is marked by the GROUP_END extension.
>
I basically agree. There is a difference in how easy it is to skip over
the group in one case versus the other, but I don't know if I would consider
that a major issue (it might be if one is trying to access a single item
nested a couple levels down in a structure with many components at each
level).

> Given that these 2 ways of grouping HDUs are so similar and provide the
same
> functionality, why go to all the trouble of inventing a new type of
> extension with XTENSION = 'FITS'?  The GROUP_BEGIN/GROUP_END alternative
> requires no changes to any FITS libraries, and requires no changes to the
> FITS Standard to be officially recognized.
>
I'm not sure I understand that last part. How can it be officially
recognized
if it isn't part of the standard? Or how does something become officially
recognized? It would seem to me that if one wants the semantics to be
recognized, then it must be part of the standard in either case. Otherwise
it is just a convention that may or may not be widely accepted.
But your main point is well taken. (I was considering similar solutions.)
At a certain level it may be more a matter of taste.

> Having said this, I don't particularly like either of these proposals
> because they are both limited to just grouping HDUs within a single file.
> Why not use the existing Jennings et al. 'Grouping' proposal, which can be
> used to group HDUs within a single file, but also provides much more
general
> support for grouping HDUs in multiple files?
>
I'm not against it in principle, but again, there is an element of weighing
a simpler and more likely to be implemented standard versus a more complex
and feature-full version which may not be accepted or implemented (there is
a connection between the last two).

To elaborate on the latter, the Jennings et al proposal is certainly
encompasses more capability and features, but presents many implementation
issues as well. One could argue that the implementation issues are
secondary.
Perhaps, but if it is left to the applications (rather than the libraries)
to deal with the bookkeeping, I'm not sure how useful it is. The
applications
(unless they are general utilities) will tend to become wired to specific
instances of grouped data sets and much of the machinery will be repeated
in different applications. the advantage of the standard in this case would
be
in the utilities available, but not in the ease of writing the applications.