[iaufwg] convention or standard

[Lucio Chiappetti]

On Mon, 9 Oct 2006, Mark Calabretta wrote:
> The "conventions in the standard" are no longer "conventions", they're   
> now standards.  Referring to them as conventions, however qualified,  
> blurs the distinction between the two.

I believe (as I just said on FITSBITS) that there are two more sources of 
confusion in the present discussion :

- one is that there are presently two different "registries" involved,
  one is the convention registry 
  http://fits.gsfc.nasa.gov/fits_registry.html
  the other one is the list of registered extensions
  http://fits.gsfc.nasa.gov/xtension.html

- the other source of confusion is that the second "convention" to be
  discussed (XTENSION='FOREIGN') is actually the definition of a new
  conforming extension so it falls in both categories !

I'll try to be practical and say that a "convention" is just a set of 
rules normally regarding presence or syntax of particular header keywords. 
It is just a variety of a given standard file layout. Recognizing a file 
conforms to a specific convention may suggest the user to use a specific 
reader, or to take particular actions dealing with the data. But the user 
can ignore the convention and still be able to read the data (say one 
receives a file containing a RMF written according to the HEASARC 
convention .... if one does not know anything about it, one can always 
handle it as a valid BINTABLE and display its content).

In this respect I agree with Thierry Forveille when he says

> Well, the "once FITS always FITS" rule is precisely what I'd like to 
> avoid for something that underwent as little review as a convention.

But the matter of a conforming extension is different ! It defines an 
altogether different file organization. There is nothing I can do if I 
receive a file with XTENSION='xxxx' and that is not one of the standard 
ones, then choke and say "unsupported extension", or write a new reader.

And here the "once FITS always FITS" comes in place. I agree with Bill 
when he says

> Another point to recognize is that adding a name to this list does not 
> necessarily reserve that name indefinitely.  For instance, it is very 
> unlikely that the 'COMPRESS' and 'VGROUP' names will ever be implemented 
> as originally suggested, so there is no reason not to reuse those names 
> for another purpose if someone wanted to.

BUT that means we should somehow formalize the procedure. I thought of a 
SIMPLE sequence of status codes, but any equivalent solution (text notes) 
will be fine:

 -1 name reserved but not documented nor implemented
 -2 name reserved and documented but not implemented
 -3 implemented for local use
 -4 under revision for insertion in the standard
 -5 standard

I believe at some stage (probably after step 2) a reservation could expire 
and being reclaimed. If we want we could state that a reservation for an 
XTENSION names can be reserved but expires automatically if not documented 
within TBD months. A documented name could expire if not implemented when 
the same name is requested by somebody else AND/OR the original proposer 
retires it. A local implementation should probably never expire except by 
request of the original proposer (so A3DTABLE and IUEIMAGE will remain 
for ever). Status 4 is transient and perhaps does not need to be marked...

... but the transition from 3 to 5 probably requires a change of XTENSION 
name (the A3DTABLE->BINTABLE and IUEIMAGE->IMAGE are examples), plus what
Doug Tody says :

> I would go one step further and suggest that if a convention is deemed
> useful enough to become a standard, it should be possible to consider
> significant revision as it goes through the standardization process.
> The resulting standard might then differ significantly from the original
> convention.  Merely registering a convention on the other hand, does not  
> require any revisions other than possibly to the documentation. 

----------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
----------------------------------------------------------------------------