[fitsbits] start of Public Comment Period on CONTINUE Long Kwd convention

[Lucio Chiappetti]

On Fri, 26 Jun 2015, Harro Verkouter wrote:
> On 26 Jun 2015, at 08:09, Tim Pearson <tjp at astro.caltech.edu> wrote:

>> 2. Although I welcome this long string convention, I'd prefer to see
>>    the standard find a more general way to allow any header record to
>>    span more than 80 characters. "Another technical team has been
>>    considering a *new* convention for long keyword name and extended
>>    character set. Since this is a new proposal, it will be most likely
>>    announced for a Public Review Period later and separately."
>>    Shouldn't we wait for this? Will it be compatible with the CONTINUE
>>    convention?

It will be compatible by construction because they address two different 
issues: long keyword NAMES, and long STRING VALUES

> I agree with this. I'd rather leave the proposed convention what it is: 
> a documented convention. There are issues with how to interpret the 
> CONTINUE - does it apply to the value, the comment, both?

It is called "long string value" so it applies to the values. It is a 
perhaps pleasant coincidence that it could allow "tricks" to extend long 
comments, but it was not its purpose.

About the word "convention" we should not be overly picky. The FITS 
standard has been growing out of accepting conventions. There are various 
items in the current (3.0) standard document [make an acroread search !] 
which are ALREADY CALLED conventions (Random Groups, Variable Arrays, 
unsigned integers, all the WCS stuff ... perhaps even the Y2K agreement).

So we have simple conventions (legal FITS constructs used only inside 
specific projects or subcommunities), registered conventions (documented 
in an accepted/endorsed way, useful to AND USED BY several subcommunities 
and proposed as examples "if you need to do X why not do like this ?") and 
conventions which are parts of the standard, while remaining optional ("IF 
you need to do X then you SHALL do it this way")

> One suggestion that I keep coming back to is to store the keyword-value 
> pairs in an ASCII table extension with two columns KEY and VALUE of 
> desired maximum length. If the table is left as last HDU in the file, it 
> can be extended easily as needed (or one can pre-allocate a number of 
> rows in the table, any FITS reader will readily accept that).

In the context of the other technical team, we have been considering the 
possibility of a thing called a "metadata HDU" to be possibly placed last 
(although the inclination was more towards a BINTABLE than an ASCII 
table), but that will be an even MORE RADICAL change w.r.t. current FITS 
than the introduction of long keyword NAMES.

Essentially the rationale about being cautious, is that completely new 
features will require more or less large changes to the readers (*), and 
extensive tests, and gain acceptance by the community (so they should 
develop as conventions before going into the standard ?), while current 
registered conventions are already legal FITS, harmless if ignored, most 
likely already supported by several readers ... so ... more mature for 
incorporation in the standard

(*) the assessment of such software changes has been of the key issues 
considered by the other team, as well as the Once FITS Always FITS 
principle

-- 
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)