[iaufwg] FITS panel recommendations; ready for review?
William Pence
pence at milkyway.gsfc.nasa.gov
Fri Jul 13 17:04:21 EDT 2007
Bob,
Not meaning to minimize your suggestions in any way, but can I assume
that none of these comments are critical enough to require that the
document be modified before starting the wider public comment process?
I think it will be more appropriate to raise these specific issues
for everyone's benefit on FITSBITS, rather than discussing them here
just within the IAUFWG.
Just one clarification regarding your last comment: A header block and
a data block are both 2880 bytes long. A FITS header consists of 1 or
more header blocks, and the data unit of an HDU consists of 0 or more
data blocks. The general term 'FITS block' simply means either a header
block or a data block.
Bill Pence
Robert Hanisch wrote:
> On 7/5/07 5:43 PM, "Steve Allen" <sla at ucolick.org> wrote:
>
>> On Thu 2007-07-05T16:46:22 -0400, William Pence hath writ:
>>
>>> Are the technical panel's recommendations ready for wider
>>> public review and comment? If not, what deficiencies need
>>> to be fixed before starting the public review process?
>>
>> Point 7 of the summary refers to section 4.1.2.3 and the added rule
>> that keywords with a value shall not be repeated in a HDU. Almost
>> every FITS file from the optical spectrographs and imagers at Keck has
>> always violated this rule. I don't defend that practice, I simply
>> report it. This new rule would ex post facto declare all those Keck
>> files to be non-conforming.
>
> I wouldn't defend the practice either, but I think it is better to provide
> guidance on what should be done when duplicate keywords are found rather
> than to prohibit their existence.
>
> Several of the changes aim to remove duplication, but #10 in Section 4.4.1.2
> inserts a duplication.
>
> I don't understand #14, as EXTNAME / EXTVER / EXTLEVEL would imply that they
> refer to extensions and not the primary HDU. I would guess that HDUNAME
> etc. have been introduced in order to construct a referencing system for the
> components of a FITS file, and I would think the distinction would in fact
> be useful rather than pedantic.
> In Other Individual Recommendations...
>
> 14, re/ DATE, the statement is obsolete but is relevant to reading FITS
> files written prior to 1 Jan 2000. Shouldn't it remain in the document so
> that people know explicitly when this rule went into effect?
> In Other Global Recommendations...
>
> 4, re/ twos-complement, this is very curious. Indeed, most documents I
> scanned on the web write "two's complement", but sometimes it is
> "two's-complement" and sometimes it is "twos complement". Obviously this is
> intended to be a possessive form, as "two is complement" makes no sense.
> Even more curious,
> http://www.answers.com/topic/signed-number-representations talks about
> "ones' complement". So, "two's complement" implies the complement is of a
> single two, and "ones' complement" implies the complement is of plural ones.
> Who knows? Personally I think the possessive does not really make sense
> here, and "twos" is functioning more like an adjective (which would make the
> original "twos-complement" more appropriate), but the prevailing usage seems
> to be what the panel is suggesting. (Sorry - that was a grammar fanatic's
> digression! Or perhaps a grammar fanatics' digression.)
>
> 9, re/ logical record... I don't think "FITS block" is particularly
> illuminating, nor does it seem quite right in terms of a hierarchy. That
> is, one or more FITS blocks comprise a header block, and a header block and
> data block comprise a header-data unit. "FITS block" sounds to me like a
> larger scale aggregation.
>
>
> All comments above are simply on the summary of changes, not on the full
> text.
>
> Bob
More information about the iaufwg
mailing list