[fitsbits] Start of "Foreign File Encapsulation" Public CommentPeriod

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 a

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
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)