[fitsbits] WRAPPING UP Public Comment Period on the CONTINUE convention

[Lucio Chiappetti]

I am providing a revised version of the text for the standard in
http://sax.iasf-milano.inaf.it/~lucio/FITS/Conventions/continue-rev3.pdf
which takes into account the points raised.

I'd ask everybody to review it so that we can proceed to a formal vote in 
the IAU FWG within a couple of days. In particular I'd ask Mark, Thierry 
and any other FWG member it they see reasons for voting NO (reply can be 
public or confidential to me).

The changes with respect to the previous draft are marked in RED (brown 
indicates the changes for the CONTINUE convention as already considered, 
and black is text unchanged). I give below a detailed rationale.

- the part of the standard actually changed is in the first three
   pages, numbered 8,9 and 16

- at page 8 in the first brown sentence of 4.1.1 I have introduced a
   red hyphen: "long-string" (hyphenated) will refer to the new (pseudo)
   data type of continuable keywords, while "long string" (no hyphens)
   remains a colloquial expression

- at page 8 in the second brown sentence of 4.1.1, and at page 9 in the
   title of 4.2.1.2 I similarly introduce the "long-string" type

- at page 9 in 4.2.1.2, 2nd column, a sentence in red forbids the usage
   of CONTINUE for mandatory and reserved kwds unless explicitly
   declared long-string. Currently none are intended (see below).

- the above changes should represent a valid compromise between the
   positions of Mark and Bill

- at page 9 in 4.2.1.2, 2nd column a clause in red explicitly specifies
   there are no limits on continuation (this should meet a comment by
   Tim Pearson)

- at page 9 at the end of 4.2.1.1 a new sentence in red should make
   a bridge between the two sections and supply a protection against
   misinterpretation of edits made and not made (described below)

- the third page, numbered 16, is unchanged wrt the previous draft

- the fourth page, numbered 66, is an excerpt of an appendix not
   part of the standard which reflects the changes made.

- the further pages contain the edits mentioned in the last red bullet
   of the appendix. Pages 35,36-40 refer to chapter 8 (WCS), pag. 42,
   44-45 refer to chapter 9 (time WCS) and pag. 49-50 and 53-54 to
   chapter 10 (compression).

   In such sections some keyword were typed (in the compact format) as
   "character". I replaced "character" with "string", as hilighted in
   red. This is just editorial and does not assume any change to the
   nature of the standard !

- In chapters of the standard before chapter 8 a more verbose indication
   of types was used (in the form "kwd XYZ value shall contain a character
   string"). Namely this occurs for

   - XTENSION, DATE (and also DATEREF and other datetime kwds),
     DATASUM and CHECKSUM. For all these the standard further details
     the content so there is no doubt these need NOT be long-strings.

   - ORIGIN, TELESCOP, INSTRUME, OBSERVER, OBJECT, AUTHOR, REFERENC,
     BUNIT, EXTNAME, PTYPEn, TOFRMn, TTYPEn, TUNITn, TNULLn, TDISPn,
     TDIMn

   in this case I am assuming the clause at the end of 4.2.1.1 applies
   and NO EDITS to the text of the standard are needed

- Currently there is no intention of declaring long-string any mandatory
   or reserved kwd, although for some (e.g. AUTHOR or OBSORBIT) this might
   be of some use. If needed we could hold a vote in the future


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