[fitsmime] Thoughts on FITS MIME types.

[Tom McGlynn]

I realize that I'm a late comer to this discussion, but I thought I'd 
give some
initial impressions...

It seems to me that this discussion of FITS MIME types is subtly 
misguided.  
I don't think the MIME type
shouldn't be used to distinguish every possible syntax,  it should be 
used to describe
the agreement under which the syntax was created.  E.g., I can use an 
XML MIME type
regardless of the shema....  Similarly I don't have a plethora of 
different HTML mime types
depending upon whether the page includes JavaScript or not.

In a situation where a user is running an application where the type of 
the incoming data
is known, the MIME type is irrelevant -- the user typically ignores
the MIME header.  The problems arise when users need to read FITS data 
of unknown
type.  If this is the case, then the reading program is very likely 
going to be a generic
FITS reader of some kind.  I.e., if I know I'm getting FITS events 
lists, then maybe
I'll be reading the data into the HEASARC's XSELECT program, but if I'm 
linking
to a URL that's a FITS file of unkown type -- so that the MIME types of 
the kind
discussed here wouldn't be known in advance -- then I'm going to putting 
the data
into something much more general like FV that can handle the program 
regardless
of which type it is.  If I really want to use different programs for 
different FITS types
it would be simple enough to build little applications that would know just
enough FITS syntax to start up the correct program.  Such intermediaries 
could
be made infinitely customizable in a way that the MIME types can't
even begin to approximate.

So personally I would advocate a much simpler approach.  I believe that
the Image/FITS specification makes sense for FITS files with no extentions
and with a 2-dimensional image.  These correspond to the notions of the
other image data sets and this very basic notion of FITS  has been used 
outside
of the standard suites of astronomical software (e.g., in versions of 
the XV program).

A second MIME type, application/FITS would be required for all other FITS
data (and would be legal for 2-d images).  Programs which access URLs which
might be FITS data of various types would need to be able to parse the FITS
files -- but I think this is inevitable anyway.   A program which 
understands
a ROSAT events list, might not able to handle one from Integral.  We should
just support a MIME type that tells us that it's legal FITS data coming down
the pipe.

I would think that the IANA would be more agreeable to a request
for just the Image/FITS and Application/FITS MIME types than for
a whole raft of types.  And I really don't think the additional
MIME types gain us much anyway.

    Regards,
    Tom McGlynn

Don Wells wrote:

>Steve Allen writes:
> > Are FITS Random Groups files in sufficiently widespread use that
> > their users can justify the creation of the one "special" category
> > of application/fits-group?
>
>Bill Cotton tells me that they are still used for interchange between
>various synthesis imaging software packages, although usage of the
>equivalent BINTABLE constructs (e.g., the FITS-IDI conventions) has
>grown steadily during the past decade. 
>
>  
>