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

[Lucio Chiappetti]

On Wed, 24 Jun 2015, van Nieuwenhoven, Richard wrote:

> Our users where wondering why so much of the comments is thrown away 
> depending of the length of the string.

Hmm ... personally I've never been very keen about / interested in 
comments (partial exception when units are indicated in comments).

For me comments are intended to be human-readable while keyword values are 
intended to be computer-readable. In generally my homegrown programs 
simply discard the comment part ...

> STRKEY  = 'This is a very long string keyword&'  / Optional
> CONTINUE  '&' / very very long comments that must be
> CONTINUE  '' / split over a very big amount of lines

The above looks a valid construct under the current convention and would 
remain such if the convention enters the standard.

but one might think of other valid and more legible constructs 
(already allowed by current standard) like

STRKEY  = 'This is a keyword of whatever length"
COMMENT STRKEY is a kwd with an optional bla bla bla bla bla bla bla
COMMENT STRKEY very very long comments that must be
COMMENT STRKEY split over a very big amount of lines

(or with blank field)

STRKEY  = 'This is a keyword of whatever length"
         STRKEY is a kwd with an optional bla bla bla bla bla bla bla
         STRKEY very very long comments that must be
         STRKEY split over a very big amount of lines

> The same accounts for the COMMENT keyword. Currently the comment keyword
> states a COMMENT with no possibility to write a comment that expands
> over multiple lines and distinguish ...

The examples above adhere strictly to the standard using COMMENT (which 
with HISTORY and '        ' (blank kwd field)) is one of the reserved 
commentary kwd name. But one might use any other VALUELESS kwd (no '= '
value indicator) (the second is debatable)

STRKEY  = 'This is a keyword of whatever length"
COMMENT:STRKEY is a kwd with an optional bla bla bla bla bla bla bla

STRKEY  = 'This is a keyword of whatever length"
STRKEY: is a kwd with an optional bla bla bla bla bla bla bla


> My next proposal is to rename the long-string feature to a long-value 
> standard. Why limit long values to strings? Why not use it for all 
> values?

Well, I would say because the convention, called "long string value", has 
been around for ages, used and proven harmless. So incorporating it is a 
small change, not violating the "Once FITS Always FITS" principle.

Introducing long keywords of any type (with the loose definition that data 
type has in FITS for kwds) would be a more dramatic change.

We have been discussing things like that in the other technical team, in 
the context e.g. of numeric array-valued keywords. I raised some variants 
like

AnArrayOnOneLine= [1.154 1.34567 9.8765 0.0 4E-3]

          1         2         3         4            8
1234567890123456789012345678901234567890...1234567890
AnArrayOnMoreLines= [1.154 1.34567 9.876... 0.0 4E-&]
CONTINUE [3 1.1111 2.22222 3.333 4.44444... 5.5555 &]
CONTINUE [ 6.6666 7.7777 ]

or more simply encoded as strings without explicitly definining a thing 
like array-valued kwds

AnArray= '[1.154 1.34567 9.8765 0.0 4E-3]'      or
AnArray[]= '[1.154 1.34567 9.8765 0.0 4E-3]'    or
AnArray= '1.1 2.2 3.3 ...'

but at the end we concluded not to proceed and limit to the simplest cases 
allowed and used by some registered convention, e.g. long string CONTINUE
and free encoding of arbitrary sequences in strings (as used for 
coefficients by some WCS convention).


-- 
------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
Do not like Firefox >=29 ?  Get Pale Moon !  http://www.palemoon.org