FITS standard--random groups and other nits.

[Tom McGlynn]

I've put together some comments on the new FITS standard.
Most of these are nits which I wouldn't worry about
in a less formal document.  In general it seemed a very
reasonable and useful. 

The one more serious comment is that the discussion of
random groups data is unnecessarily obscure.  I get the
impression that the writers were trying to 'hide' the existence
of this format.

		Tom McGlynn


Section 3:

I'd prefer to get rid of all of the "Abbreviation of" and just expand
the acronym.  If retained acronym would be a better word than
abbreviation.

ASCII blank -- This definition is misleading or incomplete.
  Something like "The ASCII character for blank which is represented
  by a bit pattern with the hexadecimal value 20 (decimal 32).
  
Byte -- Bytes are not strings.  Probably something like:
    In this document bytes are treated octets,
    a group of eight bits treated as a single entity.

Deprecate[d] -- Only the usage within this document should be
    referenced.  Also, I'd recommend not using words like "ought" since we
    are not in the business of knowing what the right decision is
    for a user.  Something like:
    Usages not recommended for use in future FITS files are marked
    as deprecated.  Deprecated FITS elements remain valid FITS.

FITS logical record -- Either bytes are 8 bits (see above) or not.
    If we want a more careful word we should probably use the
    word octet.
    
Floating point -- This can be misinterpreted as written.  Maybe something
    like:
    A computer representation of a real number -- typically subject to
    truncation error.
    
[HDU] -- is an acronym that will probably be strange to many users
    reading this document but is not visible where expected alphabetically.
    Something like:
       HDU --  see Header Data Unit
    might help users.
    
Heap -- Probably shouldn't restrict this usage to binary table extensions since
    future extensions could use it.
    
IEEE special values -- If this is actually a useful entry it
    should describe the meaning of all of the values included.
    I'd personally just get rid of it and reference the appendix
    where appropriate.

Section 4.

I find the way Random groups data are discussed here to be a little
confusing and I'd suggest that the FITS organization be given as something
like:

  Primary HDU
    Primary Header
    Either  Primary Data Array
	or  Random Groups Data
	or  nothing 
  0 or more extension HDUs
    Header
    Optional data
    
I have the impression that there's been a lot of work to avoid
treating Random Groups data as a special case, but I think it
makes the discussion harder to follow.   E.g., the way this is
structured we have a sentence "The primary HDU and every extension
HDU will consist of..." which leaves a reader wondering what happens
for a Random Groups structure since it's explicitly excluded from
both of those


I find figure 4.1 hard to read.  I think something that read
horizontally would be easier, or the vertical orientation would
be easier to read if left justified.  I.e., I'd prefer
  a(1,1,...,1), a(2,1,...1), ..., a(naxis1,1,...), ... a(1,2,...1), ...
         
	  
	  
4.4.2

It's not clear in this context that the unique type name
refers to the extension format, not to extensions within a
given file.  Maybe:

   For each approved format a unique identifier is given
   (see Appendix I).  This identifier is used as the value
   for the XTENSION keyword for any extension using this
   format.


Section 5.

5.4.2.5

I would think some reference to the standardization efforts underway
for world coordinate systems would be appropriate.  The latest draft should
be included in the bibliography.  I'd suggest that at least the
standard values for the CTYPEn keywords be included in an appendix.


Section 6.

6.3

I'd truncate the next to last sentence in the first paragraph as
"The full IEEE set of number forms is allowed for FITS Interchange."
The next sentence is redundant with the opening paragraph of the chapter.


Section 7.

I believe the opening paragraph is inappropriate.  Many of the modern
FITS readers handle random groups or can be modified to do so easily -- 
especially the large number of readers based on FITSIO.  I've
personally written IDL and Java FITS readers which handle random groups
data.  I imagine that AIPS handles random-groups just fine and I would be a
little surprised if IRAF cannot.  Many FITS readers cannot handle
binary tables but I don't see any statement telling people
not to use them.

A discussion of why random groups is deprecated should be based
upon merits of the various formats.

It is also incorrect that random groups format can be implemented
with standard binary tables as is strongly implied (though I'll grant not
quite stated) in this introduction.  To support something equivalent
to random groups, one needs to have something like the TDIM convention
but that is not part of the standard.


Section 8.

8.1.5

There may be a tiny broadening of the rules here which I'm
not sure is intentional.  I had thought that previously an
Ew.d field required an E for the beginning of the exponent
and a Dw.d required a D.  The new rule seems to be that they
are completely interchangeable -- which is fine but
makes the E and D formats completely redundant with the F format.


Appendix A:

What is the status of a card like:

    C2345678=1

I.e., I'm not sure that this is explicitly said to be illegal, but it
does not meet the criteria for either a comment card
or a value card (needs a space after the =).

Appendix F:

The image extension should have PCOUNT=0.


HTML

In the HTML version of the document there seems to be a jump from 5.4.1.1
to 7.1.1.1 and from 7.1.1.9 back to 5.4.1.2.  Somehow LaTex2HTML has
been confused.  Here I'm referring to the links using the next
and previous buttons.