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

Thu Jun 25 00:35:20 EDT 2015

Ok,

I think I understand, the wish is that old versions would not break
reading the new version files? (because of the & after the value). An
option would be to skip that & char and just use continue:

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

then old implementations would just lose the continue's. An even more
restrictive approach would be that non string continue's may only
contain comments.

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

That should not hurt in any version of a fits library.

For comment continuation it would be possible to do:

COMMENT  This is a very very long comments that must &
COMMENT  be split over a very big amount of lines.

The & sign as a last character in the comment signaling a continuation.
Again this would also not hurt any old implementation, and is a nice
feature for the new standard.

    Ritchie

Am 2015-06-25 um 06:02 schrieb van Nieuwenhoven, Richard:
> Hi,
> 
> for me the question is more why not, it does not bring more complexity.
> and uses the same principle with every card.
> 
> Again I am no fits user (aside of an amateur ccd image here and there) I
> am just bringing request's of our users.
> 
>    Ritchie
> 
> 
> Am 2015-06-25 um 04:43 schrieb William Pence:
>> Hi Ritchie,
>>
>> Your suggestion of how to continue the comment in long string keywords
>> over additional null string CONTINUE keywords is quite clever.  I will
>> probably steal this idea and implement it in the next release of
>> CFITSIO.  I also support the suggestion to add an example to the
>> documentation about this convention that illustrates this usage.
>>
>> However, I doubt if there would be much support for extending this
>> convention to other keyword data types (where the value can easily fit
>> on a single header keyword) simply to be able to continue the comment
>> field over multiple keywords.  For one thing, the keyword shown in your
>> example, namely
>>
>> INTKEY  = 1245678901234&  / Optional
>>
>> does not conform to format of any of the currently allowed keyword data
>> types.  My impression is that most FITS users find it quite acceptable
>> to simply write a long comment over multiple COMMENT keywords, often
>> times just preceding the keyword itself.
>>
>> regards,
>> Bill
>>
>>
>> On 6/24/2015 2:29 AM, van Nieuwenhoven, Richard wrote:
>>> 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
>>>
>>> _______________________________________________
>>> fitsbits mailing list
>>> fitsbits at listmgr.nrao.edu
>>> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>>>
>>
>>
> 
> 

-- 
BSc Richard van Nieuwenhoven
Software Architekt

adesso Austria GmbH
floridotower 26. Stock              T +43 1 2198790-0
Foridsdorfer Hauptstr. 1            F +43 1 2198790-13
A-1210 Wien                         H +43 664 88614710
                                    E richard.vannieuwenhoven at adesso.at
                                    www.adesso.at
-------------------------------------------------------------
         >>> business. people. technology. <<<
-------------------------------------------------------------
adesso Austria GmbH mit Sitz in Wien
Handelsgericht Wien FN231467v