Comments on FITS Standard 1.2

[Kevin Reardon]

Dear FITS committee members,

included below are my comments  and suggested corrections to the proposed
FITS standard. Overall, the committee has done an excellent job. Most of
these comments are rather trivial in nature and some may be attributable to
my misunderstanding of the FITS standards.

Section 3 :
----------
Array - "A sequence of data values, arranged in zero or more dimensions"

Array value - the definition mentions the linear transformation from array
to physical value, but I would not assume such a transformation need not be
linear (for example, the logarithmic transformation of  photographic
density to flux). True, the BSCALE and BZERO keywords can represent only
linear transformations, but that doesn't mean other transformations are not
possible.

DAT - mention that DAT is also know as 4mm tape (especially since this term
is used later in the document!). Also, why define DAT but not, for example,
Exabyte/8mm tapes?

Physical value - again, assumes all transformations are linear

Picture element - "A single location within an array" (i.e. eliminate word
image)

Record - is this the same a logical record? maybe include a "Logical record
- see Record" line.

Section 5 :
----------

5.1.1 - Syntax - header card images can also an optional values indicator
(see 5.1.2.2). The line would become "Header card images consist of a
keyword, and optional value indicator, and optional value, and an optional
comment."

5.2.1 - Character String - it seems to be permissible to use two quotes one
ofter the other ('') as a character string and one would assume this would
indicate a null value for the keyword (and in fact this simplifies the
programming of FITS readers and writers). But section 5.1.2.2 seems to
indicate the preferred way to encode a null value for a keyword is a null
field consisting entirely of spaces (so sometimes character string values
would _not_ have two quotes in the value field!). If two sucessive single
quotes are indeed acceptable, I think it should be stated clearly in this
section.

5.2.2 - Logical Variable - the heading for this section is Logical
Variable, but in other points in the document these seems to be referred to
as "Logical Constants" (e.g. the definition of the SIMPLE keyword). A
standard notation should be assumed.
If there is no free format for a logical variable, this should be clearly
stated.

5.2.3 - Integer - the definition seems to imply that numbers without
leading signs (+ or -) are not acceptable. I would think this would
invalidate many FITS headers and is contrary the common assumtion that a
number without sign is assumed to be positive (and contrary to the syntax
defined in Appendix A).
- explicity state the ASCII hex values corresponding to + and -.
- To avoid confusion, instead of "Such a representation is..." I would say
-"The integer representation described here is ..."

5.2.4 - Real Floating Point Number - "A decimal number consists of an
optional sign (+ or -) followed by a sequence of ASCII digits containing a
single decimal point ('.')" - defines signs, specifies ASCII digits and
constrains number of decimal points.
- the correct adjectival form is "fractional" - hence, the "fractional part
-of the floating point number". Technically, I guess one should also talk
-about the "integral part" of the number as well, but "integer part"
-doesn't sound nearly as bad as "fraction part".

5.4.1 - Mandatory Keywords - I would specify _where_ mandatory keywords are
required, e.g. "Mandatory keywords are required in every HDU as
described..."

BITPIX - what is the suggested value of BITPIX to use if there are no data
following the header? I think a value of zero should be acceptable in this
case, and would be consistent with the value of zero for the NAXIS and
NAXISn keywords.

NAXIS - what is an "ordinary data array"? Would it better to say the
"primary data array"?

5.4.1.2 - Conforming Extensions - it isn't clear, at least from the opening
sentence, when these keywords are considered mandatory. I would rephrase
the opening to: "When the HDU contains an optional extension, it shall also
be mandatory to include the following keywords in the primary header and
extension header."

5.4.2.1
ORIGIN - what exactly in meant by "organization"? How can an organization
physically create a FITS file? Perhaps a better wording would be
"identifying the organizational entity responsible for the creation of the
FITS file".

DATE-OBS - when referring to the DATE keyword in the first sentence, refer
to the appropriate section number as well (see 5.4.2.1).
- There is one statement in the second paragraph stating that the DATE-OBS
-refers to the start of the observations. The closing paragraph qualifies
-this by stating that this assumption shall not be made for observations
-made in the 1900's. This is all fine, but these two statements should be
-made together in a single paragraph.

OBSERVER - I would recommend that it be stated that this keyword can refer
to more than one person. I would consider rephrasing the sentence to
"identifying the person or persons responsible for acquiring the data
associated with the header".

OBJECT - accept that some objects have more than one name; switch "the" to
"a" -> "a character string giving a name for the object observed".

EQUINOX - can refer to both header and data -> "the celestial coordinate
system in which positions of either or both the header and/or the data are
expressed.

CTYPEn - I would state here that "units must follow the prescriptions of
section 5.3", since this is the only keyword of this set that actually
specifies a unit.

CRVLn & CDELTn - remove the "units must follow..." phrase (implied if these
values are given in units of CTYPEn).

DATAMAX & DATAMIN - a floating point number representation can be identical
to an integer number representation, so it would make more since to say
these fields "shall always be interpreted as a floating point number."
- I would state more clearly that these values no refer to the physical
-values, perhaps with a phrasing like "the [minimum|maximum] valid physical
-value represented in the array, after transformation to physical values
-and exclusive of any special values." (e.g. BLANK, NaN?)

Appendix A -
-----------
integer_value - here the sign is said to be optional; this needs to be
reconciled with section 5.2.3
decimal_number - the syntax here seems to imply the use of the decimal
requires the inclusion of the fractional part as well, which is not in
agreement with section 5.2.4. I think the desired syntax here would be:
 [sign][integer part]['.' [fractional_part]]  <- i.e. nested brackets

Appendix D -
-----------
"see: Explanatory Supplement ... OR http://"

"Use of GPS time (19  s behind TAI) is deprecated"
Does GPS time refer to Global Positioning Satellite time? The explanation
of the acronym should be stated.
Secondly, why is it deprecated? For many amateurs or smaller observatories
this may be the easiest way to get an precise time measurement.

Again, the trivial nature of many of these corrections testifies to the
excellent job the committee has done in preparing this draft standard.

sincerely,
kevin reardon
Osservatorio Astronomico di Capodimonte
kreardon at na.astro.it
http://arthemis.na.astro.it/