[iaufwg] FITS panel recommendations; ready for review?

[Robert Hanisch]

On 7/13/07 5:04 PM, "William Pence" <pence at milkyway.gsfc.nasa.gov> 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?

Well, as I said, I did not read the full revised document, only the summary
of changes.  I presume that is what most people will do, so if anything
needs to be changed, it is probably the summary.

o  I'd suggest rewording the first item 14, which is unnecessarily
pejorative.

o  I'd suggest clarifying the FITS block, header block, and data block
description since at least two of us were confused by it.

Bob

>    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