[fitsbits] Proposed Changes to the FITS Standard

[LC's NoSpam Newsreading account]

On Thu, 16 Aug 2007, Preben Grosbol wrote:

> It may be a matter of exact wording but the random groups header is
> the prime header.  A FITS reader which does not know about random
> groups may flag such a header as an error if PCOUNT does not
> follow directly after the last NAXISn keyword.

Since random groups were in the earliest FITS, I dare say that a generic 
or non-radio FITS reader may decide not to support them, but cannot 
afford to ignore them. They are clearly recognizable as flagged by 
GROUPS=T, so the reader or verifier *must* recognize them (and ONLY then 
*may* decide to ignore them).


On Thu, 16 Aug 2007, Eric Greisen wrote:

> Random groups is by no means a dead format. [...]
> If random groups are deprecated to the point of being illegal

Nobody is really proposing that. Actually the text of chapter 6 on 
random group (and the introduction about deprecation) is UNCHANGED with 
respect to earlier versions of the standard.

I am not sure whether the actual idea of "deprecation" arose in an 
earlier version of chapter 6 or elsewhere. Anyhow also the general 
definition of "deprecated" in chapter 2 did not change much and was NOT 
made more restrictive. 

It is (as it was originally) just a recommendation ("should") for NEW 
application, and the text added in 3.0 is a guarantee clause for OLD 
application (for them the deprecated structure SHALL remain valid).

On Thu, 16 Aug 2007, Rob Seaman wrote:

> I agree with Preben that there are also problems with introducing 
> versioning, but otherwise conformance is unenforceable.  The suggested 
> new wording of 3.7:

It might be that the text of 3.7 could be improved but what is the 
actual impact of all this ?  Does it apply to specific pieces of 
software ? to existing one ? to new one ? Or just to (human) programmers 
instead of software ?

The main point is that it does NOT force OLDER files to need to be 
rewritten to conform to new standard "additions".

Just as e.g. the Y2K change to the DATE format did not force anybody to 
rewrite old file with the new ISO timestamp.

So a generic reader might have to support older and newer variants 
(which gives a burden on us to clearly document how and when they 
changed, and from what into what). Or if it supports only the new 
variant it shall warn in case of non-compliance "maybe this is an older 
file" (or check if possible if this is the case), and be somewhat 
lenient.

However it is always possible to add a COMMENT which claims conformance 
with the latest (e.g. 3.0) standard.


Lucio Chiappetti

-- 
----------------------------------------------------------------------
nospam at mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.