[fitsbits] Start of "Foreign File Encapsulation" Public Comment Period

[William Pence]

Tom,

I'll try to address the broader questions you raise about the FITS registry, 
and leave it to the submitters of the convention to responded to the 
comments that are specific to the FOREIGN convention.

The purpose and rules for the Registry are described at 
http://fits.gsfc.nasa.gov/fits_registry_rules.html.  The basic requirements 
for a convention to be included in the Registry are:

  1 It should conform to the FITS Standard.
  2 The convention should be in actual use (this is not the appropriate
    place to propose entirely new FITS conventions).
  3 The documentation should be clear and concise.

It is easy to determine if a convention meets the first 2 requirements.  The 
main purpose of the 30-day public comment period is to address the 3rd 
requirement, i.e., to solicit comments and suggestions from the FITS 
community about the documentation.

In this particular case, the Foreign File Encapsulation convention meets the 
requirements of the FITS Standard (section 5.4.1.2) for a "conforming" 
extension.  It perhaps not well known that it is legal in FITS to invent new 
extension types, beyond the standard 'IMAGE', 'TABLE', and 'BINTABLE' 
extensions.  Appendix I of the FITS Standard lists all the "reserved" 
extension types that have been registered with the IAU FITS Working Group. 
I anticipate that the FWG will approve the addition of 'FOREIGN' to this 
list in the near future.  As you suggest, it would be "strongly discouraged" 
to use any of these registered extension names for a different purpose.

 From my own perspective I would hope that the number of new extension types 
that are created can be kept to a minimum because of the impact that it has 
on existing software and the added confusion that it can cause for FITS 
users.  The existing standard extension types (IMAGE, TABLE, and BINTABLE) 
are general enough that they should be able to contain most types of data. 
In principle, general FITS software 'should' be able to deal with any 
conforming extension type appropriately (e.g., at least be able to list the 
header keywords, and be able to skip over the HDU and continue with the next 
HDU), but in practice, many existing FITS applications will probably choke 
on an unknown extension type (including some software that I have written).

Bill Pence

Thomas McGlynn wrote:
> I'm not entirely clear on how the FITS conventions registry is
> supposed to work.   My original concept was that this was
> to be a way in which FITS data is used in ways
> that are fully compliant with existing FITS standards but which have
> additional semantics.  The registry was to
> expose these ideas so that others could adopt them into
> their own software and recognize them when we saw them.
> 
> The foreign file encapsulation doesn't really fit this framework.
> It describes an entirely new type of FITS HDU.  In the past such
> a new type would require an amendment to the FITS standard.
> So in this case is the registry functioning as a kind of second
> tier of 'approval' for a new FITS standard?  I'm not sure I
> think this is appropriate or
> at least I'd like to understand how I, as a writer of FITS
> software am expected to respond to this proposal.  If this
> standard is approved should I modify my software to understand
> XTENSION=FOREIGN?  Am I forbidden (strongly discouraged?)
> from using XTENSION=FOREIGN for my own FITS extension?  Does
> this ever move on to become part of the formal FITS standard, or are
> these conventions parallel to the standard?

-- 
____________________________________________________________________
Dr. William Pence                       pence at milkyway.gsfc.nasa.gov
NASA/GSFC Code 662       HEASARC        +1-301-286-4599 (voice)
Greenbelt MD 20771                      +1-301-286-1684 (fax)