[iaufwg] FITS panel recommendations; ready for review?

[William Thompson]

Bill:

Thanks for the clarification about blocks, that confused me too.

I'm concerned about the recommendation about preserving the order of keywords--I 
don't think it's practical.  Otherwise, I think it's ready for general 
discussion on FITSBITS.

Bill Thompson


William Pence wrote:
> 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
> 
> 
> _______________________________________________
> iaufwg mailing list
> iaufwg at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/iaufwg
> 
> 

-- 
William Thompson
NASA Goddard Space Flight Center
Code 671
Greenbelt, MD  20771
USA

301-286-2040
William.T.Thompson.1 at gsfc.nasa.gov