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

[van Nieuwenhoven, Richard]

Hello,

first a small introduction because I am new in this mailing list. I am a
developer of the java nom-tam-fits library (of Tom Mc Glynn). Together
we moved the nom-tam-fits library to github

(https://github.com/nom-tam-fits/nom-tam-fits)

where we are now working to adapt the library to the current needs of
the users. Excuse my bad English but I am not a native speaker.

One of the issues we have struggled with in the last months is the
longstring behaviour together with the possibilities of long comments.

Our users where wondering why so much of the comments is thrown away
depending of the length of the string. When a string almost fills up the
space the comment is "gone" (with longstrings enabled it happens every
time all the cards are "filled" with data.

Now we found a "hack" in the specification to allow keeping longer
comments by splitting the string over multiple lines even is there would
be enough space for the string in less cards. then spread over multiple
lines there is enough space also for longer comments.

In the current specification I did not wanted to go to extreme
situations by using string continues like this:

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

because I can imagine that other implementations would not expect such
"strange" usage. But if the new specification explicitly includes such
an usage it would be a great help for the developers.

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?

INTKEY  = 1245678901234&  / Optional
CONTINUE  567890& / very very long comments that must be
CONTINUE  / split over a very big amount of lines

That would not only allow for values with an unlimited level of
precision but also for very long comments. The COMMENT keyword is no
alternative here because it can not be automatically detected if the
COMMENT has a relation to the previous card.

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 (automatically) it from multiple
separate comments.

So in short I propose to officially allow:
1. empty string value continues to store longer comments
2. use the "long" technique for all value types
3. extend the long technique to the COMMENT keyword.

Any thought’s on these feature requests? I am no expert on the standard,
just an open source developer grown into the standard, so it could be
that I have overseen other possibilities to achieve the user requests.

	Ritchie