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

[Lucio Chiappetti]

On Tue, 12 Apr 2016, Lucio Chiappetti wrote:

> I will avoid to give here my own suggestions and opinions in this 
> introductory summary, but will post them separately.

OK, here I am.

> 4 it was questioned [that the CONTINUE convention is] de facto
>   introducing a new datatype

Well, it might well be in the eye of the beholder. This is discussed in 
appendix at the bottom. But let us assume the above as applicable to the 
majority of common cases.

Note that nothing forbids a programmer to treat all string keywords as 
long strings and use a well behaved routine which reads an uncontinued 
string as a special case of long string (I believe the CFITSIO routines 
described in the posts by Bill Pence a while ago are well behaved).

On the other hand it is understandable that a programmer mantaining an 
existing bulky software package may not want to change all types in one's 
code.

>   a the "Single record string keywords" defined in 4.2.1.1 correspond
>     to the "string" datatype as used so far.
>
>   b the "Continued string keywords" defined in 4.2.1.2 define a new
>     type which can be called "long-string"
>
> 5 it was proposed to add to the text a restriction 'CONTINUE may only be
>   used for keywords that are declared to have a value of type
>   "long-string".  It must not be used for keywords of type "string".'

> 6 the exact final wording is to be agreed, and this is the purpose of this
>   PCP.

My purpose is precisely to find out this wording.

Ideally with no or the minimum number of changes to the existing standard 
OUTSIDE of the sections being modified explicitly for CONTINUE

1) First of all, if we want to use a short nickname (like "string" and
    "long-string") we have to introduce it formally (the proper place
    would be at the beginning of 4.2.1.1 and 4.2.1.2)

2) Second we must add a sentence LIKE the one above somewhere

3) Then we must make sure that the current standard indicates a type
    for all keywords. I am pretty sure it does, although it may use
    "string" or "character" interchangeably

    The latter is formally ambiguous (if 4.2.1 is "Character string"
    both "string" and "long-string" are implied as "character" !?)

4) Obviously we do not want to change anything for mandatory kwds.
5) We also do not want to change anything for "functional" reserved
    kwds (BUNIT or TUNITn or DATASUM or WCS stuff)

6) we may argue whether descriptive reserved keywords (e.g. TELESCOP,
    INSTRUME. OBSERVER, OBJECT, AUTHOR, REFERENC, OBSORBIT etc.) really
    need to be forced as (old, short) strings. Probably not but I would
    not scandalize if we do.  Otherwise we need to edit the type for
    selected kwds, even in a future. And vote about it.

    This decision affects the content of the sentence referred in (2)

7) Strictly we can only dictate what is relevant to the standard document
    (and I could accept that all currently defined string kwd remain
    old, short string) ...

    ... but what about additional documentation (papers incorporated in
    the standard, registered conventions, project or site documentations,
    private usages) ?

    These will be using "free" (not reserved) kwds, so maybe they already
    exploit the old CONTINUE convention without explicitly stating it, or
    they may not explicitly document the type of a kwd, Or they may be
    rather keen to move to long-strings

    This also may affect the content of the sentence referred in (2)


------------------------------------------------------------------------
APPENDIX ; Well, it might well be in the eye of the beholder.

I mean it depends on the programming language, library, kind of 
application. For instance if the language supports fixed-length or 
variable-length strings. If it strongly typed or not, if typing of a 
variable is declared at compile time or dynamic (e.g. idl or python).

Definitely what CONTINUE is doing is altering the 1:1 correspondence
between a keyword and a single header keyword record (aka card image).
But this is (already) stated at the end of 4.1.1 in the new text.

Remember also that FITS is not so strongly typed (one cannot know the type 
of an arbitrary keyword without reading some associated documentation, 
just make an heuristic guess), or at least that FITS types do not exactly 
match computer language types, e.g. this is valid FITS integer kwd

RICEGRN= 18446744073709551615

but does not match any of the usual integer data types.

So if one is going to read an arbitrary FITS header and assigning each 
keyword value to an element of a structure, one has to find out 
heuristically the type of each kwd and assign it somehow to the existing 
types available in one's language. I experimented with something like that 
in IDL http://sax.iasf-milano.inaf.it/~lucio/temp/ProvaFits/fitsread.html

-- 
------------------------------------------------------------------------
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