[fitsmime] New MIME-types-for-FITS RFC draft

[Lucio Chiappetti]

I post a few comments (I try not to repeat stuff already posted, but I'm
not sure if all comments apply to CHANGED FEATURES in the draft, or to
preexisting one, since they are not marked), preceded by a quick answer to
Arnold Rots.

On Wed, 17 Mar 2004, Arnold Rots wrote:

> There has been some back and forth on gzipping and identification of
> tables.

gzipping (if you really mean it, i.e. not other forms of possibly more
efficient compression INSIDE the data part of an HDU which have been
discussed in the past) has nothing to do with a new MIME type.

A combination of decent browser and httpd server should be able to handle
a .gz file in a straightforward way using some other HTTP header stuff
(can't remember why). Consider the following *working* example.

In my XMM LSS database, I make available to users some FITS files. In
order to force the browser to download them to disk (the default action
for an "unknown" MIME type), I've taken the liberty to declare them as
"application/fits" in advance of registration (I could have used
"application/x-anything") inserting in the .htaccess file at same position
in my directory tree a line

  AddType application/fits .fits

This applies to all subdirectories below. Now some of those contains .fits
files and some other .fits.gz.

Both are automagically retrieved and expanded on the fly when saving to
disk. I did not do anything in MY configuration. There is a line in the
main configuration file of the httpd server

  AddEncoding x-gzip gz tgz

which should be responsible of this behaviour. I can't remember if it was
part of the default Apache configuration, or of our local setup.


> But it might be useful if application/fits could provide some clue as
> to the way the file is to be used/interpreted.

I believe this goes together with your reference to "identification of
tables". On the latter I'll comment further below.

I have no experience whatsoever with MIME "optional parameters" or the way
they are used. I just note that the FITS file header contains already ALL
CLUES necessary to properly handle any FITS file ("properly handle" may
also mean "sorry this feature is not supported")


Now I supply a few sparse comments to the current text of the draft


(1) page 8, section 4.7

    is there a specific reason to list the observatories in the
    presented order ? Should we use a wavelength order, or some sort
    of chronological order ?

    One could add reference to various ESA missions. I'm sure that
    XMM-Newton uses FITS format throughout. I'm not sure about
    Integral but I think so. While the original IUE (joint NASA-ESA-SERC
    mission) archives somehow pre-date FITS (or at least did not use
    it originally) I'm pretty sure the latest archives do.

    In the context of such missions one could also quote non-ESA sites
    like the XMM SSC in Leicester or the Integral ISDC in Switzerland.

(2) page 10, section 5.1, sub "Applications which use this media type:"

    Again for completeness, I would add the XMM-Newton SAS
    (http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml and
    refs. therein)

    I'm a bit puzzled by the reference to IDL (which I use) or to
    Mathematica and MatLab (which I do not know). What's the point to
    quote general data handling environment-or-languages (for IDL the
    distinction is not obvious), specially when "support" to FITS is
    provided by add-on libraries.

    If one quotes IDL, why not quote Fortran and C as well ? :-)

(3) page 10-11, section 5.1, sub "Additional information:"

    Why the conformance to published standards is a SHOULD and not a
    MUST ?

    What about the reference to "XHDUs ... of the standard types ...
    or any other conforming type" ? Do we mean only future extensions
    endorsed by the IAU, or also not endorsed extensions ?

    More generally, should we say something about what the recipient
    software may or may not do with such a broad standard ? In particular
    has the recipient software the right to refuse serving some
    particular extensions or XHDUs or combinations thereof ?

(4) page 11, section 5.1, sub "Recommendations for application writers:"

    In the second example bullet, I criticize a bit the wording
    "which encodes an image as a series of photon events". An event list
    may "encode" as well and at the same time an image, a spectrum, a time
    profile !

(5) page 14, section 5.2, sub "Applications which use this media type:"

    Why here (unlike 5.1) astronomical and non-astronomical are listed
    separately ? (may be the same should be done in 5.1 as well)

    I suppose one could add things like the ESO RTD, or Skycat. I leave
    to our ESO colleagues to supply proper references !!

(6) page 15, section 5.2, sub "Additional information:"

    I'm a bit confused here. I can definitely imagine web users outside
    of the astronomical community to be interested in FITS (plain, 2-d)
    images, and therefore accept the existence of "image/fits" alongside
    with "application/fits".

    However I wonder if more unusual forms of "images" should not be
    discouraged (i.e. accepted ONLY as "application/fits".

    For instance I wonder about the statement in parenthesis in the
    first paragraph ("In rare cases it may be appropriate to describe a
    NULL image ..."). Is it misleading ? Should it be more explicitly
    discouraged (with a SHOULD NOT if not even a MUST NOT) ?

    I believe also that (further down pag. 16, "Recommendations for
    application writers:", para 5) the usage of NAXIS=1 images should
    be discouraged (personally I'd prefer a table to store such data,
    although I admit there are cases to use an image)

    On the contrary I do not see why NAXIS=3 images should be privileged
    with respect to a FITS file made from 1 or 0 PHDU and n XHDUs which
    are EXCLUSIVELY of "IMAGE" type.

(7) nowhere special

    There are two things which are not said anywhere, and I wonder
    whether they are worth saying.

    One is a requirement or recommendation or suggestion that, in case
    a viewer is uncapable of dealing with a FITS file "displaying" it
    (whatever display may mean ... a 2-d pixel image, or an HTML view
    of a table, or a plot) e.g. because it has a combination of HDUs
    or types or keywords which are not supported, it shall/should/may
    offer the option to Save to Disk.

    My inclination is that this option SHALL always be used, and also
    that is SHALL NEVER be forbidden.


    The second thing concerns tables. I am not advocating to define a
    further MIME type for "plain" tables (similarly to image/fits for
    would-be "plain" images). As we run in difficulty defining a "plain"
    image, so we would when defining "plain" tables (one with a null PHDU
    and a *single* TABLE or BINTABLE XHDU ?  one where all columns have
    "depth 1" ?)

    Nevertheless we could suggest a recommended way of displaying any
    tabular XHDU. This should be to render it textually, as an HTML table
    with the cells rendered according to the appropriate format
    (e.g. TDISPnn or alike ; n-depth column elements may pose some
    problems). Is this something we should worry about in the RFC, or
    do we leave everything to the developers ?

    I guess many of us have some CGI scripts rendering FITS tables
    into HTML pages (I have one for my own use which I developed
    independently after a conversation with Clive Page which has his own).
    I'm not sure how one does transform a CGI or external program into
    something integrated in the browser, or in a browser plugin (of
    course one can always define an external program as an external
    viewer in .mailcap or equivalent, but I guess that's too naive)

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