more on FITS and VO

[Jonathan McDowell]

Mike wrote:
> So for image/fits I
> SHOULD send only a SIMPLE FITS file but I MAY include extensions.  Why
even allow that in the first place?

Because there are plenty of multi-extension files consisting of
an image and further extensions which are not essential for interpretation
of that image. (As one example, we have X-ray spectra which store an
image of the extraction region in the primary array. You don't need
to care that the file has a spectrum in order to do something with the image
of the extraction region). 
 I'd like to be able to serve up such a file for an image request. I don't
want to be forced to strip out only the image array. (Some of your later
comments talk about padding NAXIS=0 cases, which also implies changing
a file from the archive before you send it down the wire. Although
this might become good VO practice, for the purposes of defining a FITS
mime type I'd like to insist that a file consisting of a primary image
array plus miscellaneous extensions, even a primary image array with
0 pixels, IS A valid FITS image in the traditional sense - that it
is the tradition and intention of FITS extensions that such files
may validly be interpreted as a simple FITS image by simply ignoring
the extensions. Of course such files can also be described as
application/x-fits and you can do more with them in this case, but
I don't see a problem with permitting a service responding to a 
request for image/fits being allowed to serve up such files and
claiming that they are indeed image/fits. Now in the NOAO approach
of (if I understand correctly) representing mosaic images as
one chip in the primary array and a bunch more in image extensions,
doing this would be unhelpful to the user and you would probably not
choose to represent them as image/fits. But there are plenty of cases
where it does make sense.)

  Jonathan