The following text contains extracts from discussions on the IAUFWG
email list that took place prior to approving the FOREIGN convention
for inclusion in the Registry of FITS Conventions.  

######################################################################

Subject: Re: [iaufwg] approval of the 'FOREIGN' extension convention
From: Lucio Chiappetti
Date:Tue, 12 Dec 2006 17:08:32 +0100 (CET)
To:IAU-FWG 

On Wed, 6 Dec 2006, William Pence wrote:

> > A revised document that describes this convention (in MS Word and PDF
> > formats) has been placed on the FITS registry web site at
> > http://fits.gsfc.nasa.gov/fits_registry.html.   

> > Please review this document for yourself, and let me know if you have
> > any further comments or objections about this convention;  

Surely we cannot have any objection about the convention, as the purpose 
of the registry is to track a convention which is : (a) in use ; (b) 
adequately documented.  I have however the following comments on the
document :

 - there are parts, like the entire section 4, or the explanatory
   text to FG_COMP. which are probably "over-documentation". I mean,
   they look like design notes, not usage notes.
   
   Also I'm slightly confused by the usage of past, present and future 
   tenses. I assumed that the FOREIGN convention was defined and 
   implemented long ago for "its own purposes" and then "frozen" (was it a 
   wrong impression ?), so it looks strange to "reserve" a keyword for 
   future use, or to write section 4 as requirements for something to be 
   written.

 - I have not retained a copy of the original document, and I can't
   remember if keyword FG_MTYPE was in there. If it was not, it would
   be strange to add it now. If it was, it seems strange to make
   reference to a MIME type, when probably this concept did not exist
   when the convention was first defined. Sort of "a posteriori history
   editing" ... 

   But I might have understood the time frame wrongly.

None of the above comments precludes the acceptance of the convention.

Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) 

######################################################################

Subject: Re: [iaufwg] approval of the 'FOREIGN' extension convention
From: Doug Tody 
Date:
Tue, 12 Dec 2006 09:25:52 -0700 (MST)
To: Lucio Chiappetti 

Lucio -

I agree that the purpose of registering FITS conventions is primarily
to document existing practice, however it seems fine if the authors of
the convention want to make minor changes or updates when this is done,
particularly if the convention is still in use.  The authors can judge
the impact if any on existing implementations.  If there is any concern
it might be useful be useful to note such revisions in an appendix.

In this case the document is a revision of the original design
specification, which probably explains the "over documentation" you
refer to.  Since a convention like this is in part a view into the
past, it may be better to avoid extensive changes to the document,
as even the authors might well disagree now with the decisions which
were made in the past, which reflect a different time.

 	- Doug

######################################################################

Subject:Re: [iaufwg] approval of the 'FOREIGN' extension convention
From: Mark Calabretta 
Date: Wed, 13 Dec 2006 13:01:35 +1100
To: IAU-FWG 

It is not actually stated anywhere that a FOREIGN extension stores a
single file.  (Or if that is not true then there's even more explaining
to do.)

It is not explained how "The FG keywords are used ... in standard FITS
extensions such as IMAGE, BINTABLE, and so on".

I would have though that implementing the FG_TYPEs of "directory" and
"symlink" would be a simple matter of naming them and, for symlinks,
the target.  Are they really "implementation dependent"?  If so, this
requires more explanation.

Why is it necessary to distinguish an FG_TYPE of "FITS", and moreso
"FITS-MEF"?  Couldn't any general FITS file be stored as type "binary"?
It seems that FITS files are treated specially but without explanation.

With respect to FG_LEVEL, it is not adequately explained how a directory
tree may be reconstructed, i.e. how is a file associated with a
(sub-)directory?  I don't see how it can be done.

What is the distinction between FG_SIZE and PCOUNT?

FG_FMODE is not adequately explained - it clearly shows a unix bias.
How would it be interpreted by, say, a Windows programmer who knew
nothing about unix?

The three sentences beginning "When a file group is restored ..."
make no sense to me.

Much of Sect. 4 seems irrelevant to me.  How would it help someone to
create or interpret a FOREIGN file extension?  Instead, there should be
more explanation of how the basic types "text", "binary", "directory"
and "symlink" are meant to be stored, i.e. not as an implementation
issue.


Cheers, Mark

######################################################################

Subject: Re: [iaufwg] approval of the 'FOREIGN' extension convention
From:  Doug Tody
Date: Mon, 5 Feb 2007 17:58:49 -0700 (MST)
To: Mark Calabretta

I think our main point here is to document existing conventions, already
in use, which are not standards.  The main point made earlier in regard to
the FOREIGN extension, was that if we had it all to do over again today,
we might have done something somewhat different, and is is some years
later.  Hence to make extensive changes to the specification would in effect 
mean we are creating a new convention.  That might be useful, but
that is not what the convention in question is; it is an older convention,
currently in use (maybe we should just put a date on these?).  - Doug