Comment on draft FITS standard revision 1.2

[Steve Allen]

Many thanks to the NOST Technical panel for putting this together.

Section 5.2.1

Now the minimum string length is no longer required to be 8 characters.
Presumably a null string is now a legal possibility, represented
AKEYWORD= ''
I've written regular expressions which correctly interpret this, but
does this need any special mention to distinguish it from a broken
attempt to encode an apostrophe?

Consider pathological cases akin to
AKEYWORD= ''    / isn't this funny?  'concatenated'' ''comments'

5.2.4 and 5.2.5 vis a vis 8.1.5

I am aware of the existing cases of FITS ASCII tables where there are
spaces embedded within integers and floating point numbers.  Does the
new prohibition against spaces within real and floating point values
imply that there are no known cases of FITS headers with embedded
spaces in the keyword values?

I know that I have constructed such things while exercising FITS
reading code, so it seems dangerous to proclaim that they need
not be handled anymore.

5.4.2.2

This is something I wish I'd caught during the wordsmithing of the Y2K
text.  The intent of the phrase
"shall be UTC for dates since 1972 and UT before" is perfectly
clear to someone who understands that the UTC epoch began
1972-01-01.  To others, however, it would be clearer if the
text were more explicit, say
"shall be UTC for dates beginning 1972-01-01 and UT before".

5.4.2.5

The definitions of DATAMAX and DATAMIN might be a little clearer if
the wording was "maximum valid physical value represented by the array"
instead of "in the array".  This would serve to emphasize that the
DATAMAX/MIN apply to the values after application of BSCALE/BZERO.
Alternatively, other language could make this equally clear.

8.3.2

TFORMn values for binary tables will all-too-soon face the need
for 64-bit integers.  The P format could be pressed into service
for this, but it would be better if the question of 64-bit integers
were addressed directly.

8.3.4

Data display of binary table data requires the FORTRAN behavior of
writing asterisks ***** when the value does not fit the field.
Is this constraint really necessary?  Can't we permit a broader
view of data than this, such as is seen in C printf?

Appendix A

I can't say thanks enough to those who worked out the BNF.  With this
it looks like Don Wells might simply write a one or two page RFC
proposing the FITS MIME types and incorporate NOST 100-1.2 by
reference.

For tidiness, page 53-54 splits the definition of decimal_number
across the page.  These definitions would be best not broken.

Appendix E, point 34

there's a typo BIMTABLE instead of BINTABLE
-- 
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.borg     Voice: +1 408 459 3046     FAX (don't): +1 408 454 9863
WWW: http://www.ucolick.borg/~sla               PGP public keys:  see WWW
Junk mail is irrelevant -- my return address has been assimilated.