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

[Mark Calabretta]

On Wed, 20 Apr 2016 23:12:20 -0400
William Pence <William.Pence at nasa.gov> wrote:

Hi Bill,

> So it seems we now agree on creating two classes of string-valued
> keywords.  I would simply like to assign the labels "string" and "long
> string" to them. 
>
> No, I don't agree.

Eh?  You say

 "The CONTINUE keyword must not be used with of any of the mandatory or 
  reserved keywords defined in this standard unless explicitly stated 
  otherwise."

So these non-continuable keywords are one class, the continuable ones
are another.

>  But in any case, you seem to be missing the main 
> point that the CONTINUE convention is almost exclusively intended for 
> new project-specific keywords that are not defined in the FITS standard.

Intention is one thing (on the road to hell), but I am responding solely
to the proposed change to the standard, which places no reservation
whatsoever on the use of CONTINUE.
 
>   Even if it made sense to do so, there is no mechanism in place for 
> projects to declare that the new keywords that they create are of type 
> "string" or type "long string".

That's not a problem to implement.  WCSLIB already contains a generic FITS
header parser, fitshdr(), that recognises (a generalisation of) CONTINUE. 

> Whether some of the string-valued keywords that are defined in the FITS 
> standard are allowed to use the CONTINUE convention or not is a 
> secondary issue.  In my opinion, only about 7 of the 29 (if I counted 
> correctly) string-valued keywords that are currently defined in the FITS 
> standard could conceivably ever have a value more than 68 character long 
> (ORIGIN, AUTHOR, REFERENC, OBJECT, OBSERVER, TELESCOP, and INSTRUME).

Also WCSNAME and CNAMEia, which are as likely candidates for continuation
as any of the above.
 
> Finally, as I described in more detail in a previous email, the next 
> release of CFITSIO will support a new paradigm for reading string-valued 
> keyword.  These new routines will transparently read any string keyword 
> (whether it uses CONTINUE or not) and will provide an easier way for C 
> and Fortran programs to read string keywords of any length. I think this 
> new interface will alleviate most of the practical implementation issues 
> for C and Fortran programmers that you seem to be concerned about.

That is not at all what I am concerned about!

Regards,
Mark Calabretta