Proposal 2: To increase the allowed length of string keyword values

Definition

This long string-valued keyword proposal provides a mechanism for assigning a character string value to a FITS keyword that is longer than can be expressed on a single 80-character keyword record. The long character string value is divided into multiple substrings, each of which is short enough to fit on a single keyword record. (Any single quote characters that are embedded within the string must first be expanded into two successive single quote characters). A back slash ("\") continuation character is appended to all but the last substring, then all the substrings are enclosed within single quote characters and written to a sequence of 80-byte keyword records. The first keyword record is constructed using the actual keyword name; the keyword names on all the subsequent continuation keyword records have an underscore character followed by an integer sequence number appended to that same name. The sequence number on the first continued keyword record must be the number 1 (without any leading zeros) and the sequence number is incremented by 1 on each subsequent keyword. It is recommended, but not required, that these keywords appear in order in the FITS header without any intervening keyword records.

The first keyword in the sequence has the "= " value indicator between the keyword name and the value string. All the subsequent keyword records do not have the value indicator; the keyword name and the quoted substring are simply separated by one or more space characters. Thus, under the current rules of the FITS Standard, the continued keyword records do not formally contain a keyword value.

Examples

The following keyword records conform to this convention:

00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
ABSTRACT= 'Fifteen spirals are now available for which the sense of the spiral\'
ABSTRACT_1 ' pattern and the sense of the spectrographic rotation are known an\'
ABSTRACT_2 'd in which there is conspicuous dissymmetry of obscuration.'

Note that it is not required that each substring completely fill each keyword record. In principle, each keyword record may also contain a comment field, as shown below.

00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
ABSTRACT= 'Fifteen spirals are now available \'    / Article by E. Hubble       
ABSTRACT_1 'for which the sense of the spiral \'  / published in 1943          
ABSTRACT_2 'pattern and the sense of the spectrographic \'  / in the Ap.J.     
ABSTRACT_3 'rotation are known and in which there is \'                        
ABSTRACT_4 'conspicuous dissymmetry of obscuration.'

Discussion

This proposal assumes that the keyword names may be more than 8 characters long, as described in Proposal 1.

The main advantage of this proposal over the existing CONTINUE convention to represent long string values, that has been in use for many years (especially within the high-energy astrophysics community), is that the current proposal explicitly defines the order of the continued keywords and hence is not affected if the order of the keywords in the FITS header is changed.

The back slash continuation character serves as a flag to the keyword reading software that this keyword record is probably continued on another keyword record. The continuation character is appended to the character string itself (rather than external to the string value, for example, in the 80th character of the keyword record) to make the continuation character more prominent to both software and to human readers. Note that if a keyword string value ends with the continuation character, but there is no valid continued keyword record in the FITS header, then that continuation character should be considered to be literally part of the value string.

The lack of the "= " value indicator in the continued keyword records serves to help insulate them from corruption by existing software that does not support this convention. Since these keyword records do not formally contain a value, it is less likely that existing software would attempt to modify them. Such software should treat these keywords in the same way as COMMENT or HISTORY keywords that also do not have a value.

Proposal 3: To allow additional characters in keyword names

Definition

In addition to the digits 0 through 9, the uppercase Latin alphabetic characters "A" through "Z," and the underscore and the hyphen characters, the following set of ASCII characters are allowed in FITS keyword names:

• The "period" or "full stop" character: "." (ASCII decimal code 46)
• The dollar sign character: "$" (ASCII decimal code 36)
• The lowercase Latin alphabetic characters "a" through "z" (ASCII decimal codes 97 through 122)

Discussion

Keyword names shall be interpreted as case-insensitive. Software should preserve the case of the keyword names when displaying or copying keywords, however, any searches or comparisons that are performed on the names should behave as if any lowercase characters are first converted into uppercase.

All the mandatory and reserved keywords that are defined in the FITS Standard must always be represented as shown, with only uppercase characters.

Proposal 4: Definition of a FITS version keyword

Definition

FITSVERS keyword. The value field of this optional reserved keyword shall contain a floating-point number that corresponds to the version of the FITS Standard document to which the FITS file was designed to conform. This keyword may only appear in the primary header and must not appear in an extension header.

Discussion

This keyword may be used to indicate which version of the FITS Standard document was current when the FITS file was designed. FITS reading software may potentially use this information to decide whether or not it is prepared to handle a FITS file of this particular vintage, or to anticipate which particular FITS format conventions may or may not be present in the file.

For the record, here is the complete list of all the past and current versions of the FITS Standard:

      Version     Publication Date
        1.0         6/1993
        1.1         9/1995
        1.2         4/1998
        2.0         3/1999
        2.1        12/2005  (also known as version 2.1b)
        3.0         7/2008  (current version)

Proposal 5: A convention for pre-allocating space in FITS headers for future use

Definition

Any completely blank FITS keyword records (filled with 80 ASCII space characters) that immediately precede the END keyword should be considered as unused non-significant space that may be reused when appending new keywords to the header. The first non-blank keyword that preceeds the END keyword marks the 'effective' end of the header. When a new keyword is appended to the header, it should be written immediately after this effective end keyword.

By default, this unused header space, if any, should be preserved when copying the FITS header to a new file.

Discussion

This convention allows the creator of a FITS file to reserve space in each FITS header for additional keywords that may be written at a later date. This is especially useful when dealing with very large FITS files, where there is significant overhead associated with inserting a new header block to make room for more keywords (which requires rewriting all the subsequent data).