[fitsbits] start of Public Comment Period on blank header space convention

[Mark Calabretta]

On Fri, 19 Jun 2015 12:24:31 +0200 (CEST)
Lucio Chiappetti <lucio at lambrate.inaf.it> wrote:

> The proposed draft text is available at
> http://sax.iasf-milano.inaf.it/~lucio/FITS/Conventions/headerspace-upd2.pdf

This is something I wanted years ago.  Too late now though.

- Clearly, the standards process in FITS is so traumatic that it's
  difficult to break free of the "convention" mindset!  In the proposed
  text, replace

    By convention, a sequence of one or more...
    This convention enables...
    ...this convention only be used...

  with

    A sequence of one or more...
    This technique enables...
    ...this technique only be used...

  or maybe "construct" instead of "technique".

- You don't need to say "completely" blank.  Going the extra step in
  italicising it is *completely* melodramatic!

- "overwritten" is one word.  If the space is overwritten then it is
  reused.  Hence "over written and reused" is tautological.  Thus

    ...fill space that may be overwritten when new keywords are appended
    to the header.

- Is it time yet to start referring to "keyrecords", "keyvalues", and
  "keycomments", or is that going too far?

- I don't believe it is correct to italicise "may" (twice).  It's
  already legal (and safe) to overwrite blank keyrecords before the END,
  you don't need permission from the FITS standard to do so.

- Replace

    ...created; this...
    ...are written to the header...
    ...will eventually be written...

  with

    ...created.  This...
    ...are appended to the header...
    ...will eventually be appended...
    
  (I'm pretty sure that semi-colon is incorrectly used.)

- Not "computationally" expensive but "i/o" expensive.

- "expensive alternative of having to repeatedly insert a new FITS block
  into the header to make room for 36 more keywords at a time."

  ...but why not make space in one hit for all the keyrecords you intend
  to append?

  I'm ignoring that split infinitive.  Oh, darn...

- There is nothing in the standard that prohibits the insertion of an
  indefinite number of blank keyrecords before the END.  Nothing that
  even vaguely suggests that it not be done.  And nothing that prohibits
  overwriting them.  So, notwithstanding the above, this is not actually
  a new standard, just a way of advertising a technique that is already
  legal in FITS.

- I don't think the last paragraph belongs in a standards document.

In order to use this, a FITS writer would have to read the header to
the END, taking note of its location and that of the last non-blank
keyrecord, and check for any intervening blank keyrecords.

Perhaps it would be simpler just to define a keyword (PSEUDEND maybe)
that told the writer that it was ok to start overwriting keyrecords,
whether blank or not, from "this point" to the END.  The PSEUDEND
keyword would also tell FITS readers not to bother reading further
unless looking for the start of the data section.  It would also cast
this technique in concrete as a real standard.  

BTW, this PSEUDEND suggestion, and my previous one of signalling use
of the Green Bank convention, are examples of why I think adopting
conventions, unaltered, as standards is second-best practice.  Whereas
conventions try to work within an existing framework, to do the job
properly, it may be preferable to extend the framework itself.  Like
the guy said, "conventions are not standards".

Regards,
Mark Calabretta