[fitsbits] versioning vs. schema -- where does it stop?

[LC's No-Spam Newsreading account]

On Thu, 16 Jun 2005, Thierry Forveille wrote:
> Francois Ochsenbein writes:

>  > ===> I was in fact thinking on a really light-weight mechanism --
>  >      for instance just a recommendation to include a version

I do appreciate a light-weight mechanism. However if that is *only* a 
recommendation, we should define what should be default implied if the 
version indicator is missing (lowest version ?)

>  >      number of smething similar in comment part of the SIMPLE

However I do not think the comment field of an existing keyword is the 
right place. It should be some dedicated keyword, like e.g. the LONGSTRN 
keyword used to flag files adhering to the "long string convention".
 
>  >      keyword if the FITS file potentially makes use of the 64 bit.
 
Also I'm not sure the version flag is really The Necessary Thing To Do 
concerning the "documentation of presence" of the (future) 64-bit 
proposal/s. It is already documented per se (by the presence of BITPIX 
64, TFORM K or Q pointers). A piece of s/w can simply declare them 
"unsupported".

More tricky is the issue of more subtle implications on header keyword 
(since they are not strongly typed). For instance if usage of 64-bit 
quantities requires a NAXISn keyword to be a string longer than the 
number of digits in a 32-bit integer ... what will be the implication on 
existing readers ?

This is a thing which some header mechanism shall forewarn the reader 
(but since is not forbidden by the existing standard nor explicitly 
required by the new proposals, probably won't be covered by a versioning 
mechanism).

> we'd need a central authority keeping track of what is what
 
Sure.
If we'd do it, how would we do it ?

 - consider version 0 (or default) what actually exist in the standard
   AT THE PRESENT TIME
 - increment version number at each new bunch of changes to the standard
   (which would suggest to vote new changes together)

 or try to reconstruct past history, e.g.

 - version 0 would be the original basic FITS (1981)
 - version 1 generalized extensions and ascii tables (1988)
 - version 2 image extensions (1994)
 - version 3 binary tables (1995)
 - version 4 the recent incorporation of conventions (april 2005)
 - version 5 the 64-bit stuff

 ... not sure whether and where all the WCS stuff fits in there

 or something intermediate, e.g. 0 will be the 2001 A&A paper which
 is comprehensive of 0-3 above, and we increment from there ?

Note that the above does not cope with widespread "conventions" which 
are not part of the standard (LONGSTR, HIERARCH etc.)

Should we instead use (somewhere in the primary header to be 
encountered soon by readers) a keyword marking a list of "conventions" 
or "features" adhered to by the file ? something like

CONVENTN='BINTABLE,64BIT,LONGSTRN,WCSII'

What is the likelihood that readers will actually use it ?

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