[fitsbits] Proposed Changes to the FITS Standard

On Monday 23 July 2007 21:03, William Pence wrote:
Please post any comments, suggestions, or concerns regarding these
proposals (or any other suggestions for improving the Standard document)
here on the FITSBITS email list, or on the associated sci.astro.fits
newsgroup. * Comments may also be submitted to any member of the FITS
technical panel that produced these recommendations (listed below).

After some delays I finally had a chance to go through the changes to the
FITS standard as proposed by the technical panel.

First of all my congratulations to the panel for its excellent work which has
produced much more consistent and readable standards document. During
my reading I did not come across any major issues but there are several
points which are important enough to raise. Taking first section 1 of the
summary:

4. Section 3.5 Deprecate 'special records'

I think it's okay to deprecate 'special records' as the general
extensions should be able to handle our future needs. In an
age with computer virus, it may be safer to have some handle
on what can be in a FITS file.

5. Section 3.7 Restrictions on changes

The argument is understandable but the implications very wide.
It would allow dramatic changes such as redefinition of keywords.
Something like this is needed but we may need to consider the
best wording.

7. Section 4.1.2.3 Repeat of keywords

It may be too strong to forbid such repeats of keywords. It should
certainly be deprecated but it may place a significant load on many
applications which just want to add some keywords to a header.
They would be required to actually check if they would duplicate
or not. A deprecation and definition that the last value takes
precedence may be more appropriate.

11. Section 4.4.1.2 PCOUNT and GCOUNT

In principle okay but one should check if this would require
existing software to be changed. There may still be legacy
tasks which write e.g. Random groups format. The new
section 3.7 would not work in that case.

15. Section 4.4.3.1 Reference to specific extensions

As there are many recommendations in the document, it would
be good to retain a deprecation of explicit reference to other
extensions. The point is broken links if HDU's are moved.
This opens the old issue on how to create a unique reference
to any HDU. It would be an advantage for some applications,
such as in interferometry, where cross-references between binary
table sometimes are used.

17. Sections 7.2.2 and 7.3.2 TTYPEn

The reason for avoiding '-' was the mapping of the TTYPEn names
into variables is some languages. It is irritating to have '-' in
keywords for the same reason and most applications would just
substitute them with '_'. I would either retain the old wording or if
'-' should be allow at the same point deprecate the usage of it.

20. Section 7.2.5 Deprecate implicit decimal point

We should check it with the data centers. The reason for including
such cases was to accommodate direct encoding of legacy tables
which could have used such formats to save space (at the time
when a punch cards was real and only had 80 columns).

Going through the actual text I noticed the following minor points:

- It would be better to name Appendix A 'Formal Syntax of Keyword Records'
to be in line with section 4.1

- The font of COMMENT in section 4.1.2.2 seems wrong

- It would look nicer to start the table with BITPIX 8 in table 4.9 and 7.7

- Since the description of WCS keywords like CDELTn was moved to section
8, it would be good to have a reference to that section in section 4.

- It may be good to repeat a reference to fortran in the description of the
TDISPn keyword in 7.2

As said before - my compliments to the panel
for very good work,
Preben

On Fri, 10 Aug 2007, Preben Grosbol wrote:

11. Section 4.4.1.2 PCOUNT and GCOUNT

In principle okay but one should check if this would require
existing software to be changed. There may still be legacy
tasks which write e.g. Random groups format. The new
section 3.7 would not work in that case.

I am not sure what you mean here ? The fact that PCOUNT and GCOUNT are
inthe 5th and 6th place in table 4.8 ? But table 6.1 shows (correctly)
them in arbitrary position for random groups !

And random groups are NOT a "generalized conforming extension" but
something which pre-date them (maybe this could be stated more clearly).

Lucio Chiappetti

--
----------------------------------------------------------------------
is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

On Monday 13 August 2007 15:40, LC's NoSpam Newsreading account wrote:
I am not sure what you mean here ? The fact that PCOUNT and GCOUNT are
inthe 5th and 6th place in table 4.8 ? But table 6.1 shows (correctly)
them in arbitrary position for random groups !

It may be a matter of exact wording but the random groups header is
the prime header. A FITS reader which does not know about random
groups may flag such a header as an error if PCOUNT does not
follow directly after the last NAXISn keyword.

In principle the new Sec. 3.7 introduces a FITS version that is
in FITS v3+ certain things are not valid any more. We previously
were very reluctant to introduce the concept of versioning but maybe
it cannot be avoided. It is a rather principle matter which should
be discussed in some detail (maybe at the ADASS BoF).

Preben