[fitsbits] further reopening of Public Comment Period on the CONTINUE convention

[Jessica Mink]

I'm to have to go with the idea that this is a new data type. My 
WCSTools software treats each line in a header independently and expects 
the meaning of a non- COMMENT or HISTORY line to be explicit from its 
keyword. CONTINUE header lines are dependent on their meaning from the 
keyword of a previous line. At the extraction level, I treat keywords as 
context-free values, meaning that strings can be read as numbers and 
vice versa..  I guess I would know from the presence of quotes that a 
string might be continued with a CONTINUE card, but it would add 
overhead to have to check every string keyword value and every CONTINUE 
value for a following CONTINUE lines.

I could live with that, but I prefer the IRAF convention of sequentially 
numbered strings, which I had to implement to deal with IRAF world 
coordinate systems.  It is easy to search for KEY_1 if KEY is not found, 
and having found that, look for KEY_2, etc., completing the string when 
no more KEY_n lines are found. And that convention has been around in 
optical astronomy for quite a long time, too.

-Jessica

On 04/19/2016 08:21 PM, William Pence wrote:
> On 4/19/2016 6:07 AM, Mark Calabretta wrote:
>> On Tue, 19 Apr 2016 00:19:43 -0400
>> William Pence <William.Pence at nasa.gov> wrote:
>>
>>> "The CONTINUE keyword must not be used with of any of the mandatory or
>>> reserved keywords defined in this standard unless explicitly stated
>>> otherwise."
>>>
>>> Would adding this restrictive language to the current proposal make it
>>> acceptable to everyone?  If not, please speak up.
>>
>> That would address my immediate concern, though I feel that it misses
>> the point that CONTINUE'd strings are effectively a different data type.
>
> I think the argument that CONTINUE'd strings are a fundamentally 
> different data type is tenuous at best.  For one thing, if the 
> CONTINUE convention is used to represent a string value that is less 
> then 68 characters long (and hence could have been represented on a 
> single header keyword), then this is simply a different way to 
> represent (or serialize) the exact same character string.  In this 
> case, both the nom-tam-fits Java library and the CFITSIO library 
> (beginning with the next release) will transparently read either 
> method of representing the keyword and the application program that is 
> reading the string keyword value will be unaware of which method was 
> used to originally write the keyword.
>
> Similarly, it is hard to see why a CONTINUE'd string value that is 69 
> characters long should be considered a different data type from a 
> string value that is 68 characters long (whether it is represented as 
> a single keyword or uses the CONTINUE'd convention).
>
> I think the most that can be said is that the string length *might* 
> present some language-dependent software implementation issues, but 
> this is not a fundamental property of the FITS keyword itself.  For 
> example, the string length is a non-issue for programs written in java 
> because there is no need to allocate or free the memory needed to 
> store the string value.
>
> Memory management for the string values can be more of an issue with C 
> and Fortran programs, but it depends greatly on exactly how the 
> program is written.  For example, if the program calls the so-called 
> 'long-string' keyword reading routine in CFITSIO, then CFITSIO itself 
> takes care of most of the memory management issues.  The next release 
> of CFITSIO, next week, will also introduce a new string keyword 
> reading routine which lets the reading program decide the maximum 
> length of string that it is prepared to read, thus eliminating the 
> arbitrary 68-character demarkation point.
>
> Finally, perhaps the most important thing to keep in mind is that when 
> the CONTINUE convention was invented 20-some years ago, the HEASARC 
> *never* intended to use it with any of the string-valued keywords that 
> were already defined in the FITS standard.  It was *only* intended for 
> use for new mission-dependent keywords that were created by the 
> HEASARC.  This is why I suggested adding that sentence that prohibits 
> using CONTINUE with any of the existing keywords unless explicitly 
> stated otherwise.  If and when new reserved string-valued keywords are 
> added to the standard, a decision can be made at that time as to 
> whether that keyword may be CONTINUE'd or not.
>
>
> regards,
>
> Bill
>