[iaufwg] Appendix A, END keyword

[Dick Shaw]

I understand and sympathize with the opinion that it would be better to 
document the various syntactic gotchas, rule tightening, forgiving (lax?) 
implementations, faux-pas, and so forth that dot the history of FITS. But 
rather than clutter the Standard itself, I wonder if the content is more 
suitable for another document--perhaps a web-based hitchhiker's guide?  Such a 
collection would always be incomplete, but would I think be useful to many 
even after the first few entries.

OTOH, I think it would be a disservice to reduce the FITS Standard to a mere 
implementation guideline. I think it can be made perfectly clear whether a 
given file conforms to the FITS Standard or not. However, this does not 
preclude FITS readers from being more forgiving. The Standard, I hope, will 
encourage those so inclined to implement more rigorous writers from here on.

-Dick

On Thu, 20 Mar 2008 15:03:34 -0700
  Steve Allen <sla at ucolick.org> wrote:
> On Thu 2008-03-20T17:42:23 -0400, William Pence hath writ:
>> The END keyword on the other hand is prohibited from having an '= ' in
>> bytes 9-10, so it is not necessary to make it as a special case in this
>> grammar.
> 
> I regret to admit that, among other mistakes, despite it always having
> been illegal, there are FITS files written at Lick which have a "="
> character following "END     ".
> 
> And in this regard I find myself wondering even further about Mark
> Calabretta's wish for a listing of all the syntactic elements of FITS
> which were once legal but which are now not legal.
> 
> Is it within our means follow the Jon Postel advice on internet
> protocols in the RFCs and make the FITS standard into an
> implementation guide detailing the conservative scope of what a FITS
> writer MUST do and also the liberal scaope of what a FITS reader
> SHOULD do?
> 
> The heuristics in various implementations of FITS readers (as only one
> example, Doug Mink's FITS WCS reader) are far more liberal than the
> any form that the standard admits.  Although that broad scope leaves
> open the possibility of ambiguous interpretation, there are a lot of
> applications where that is preferable to rejecting a FITS file which
> does not strictly conform to the standard.  I'm not sure how we dare
> go any farther than to leave a record of discussion in which we point
> out that implementors may wish to consult particular existing code for
> ideas on reading old FITS files.