Spectrum message self consistence

[Mike Fitzpatrick]

On Thu, May 8, 2008 at 6:42 AM, Isa Barbarisi
<Isa.Barbarisi at sciops.esa.int> wrote:
> Just another little question, that may be related with my previous post.
>  Is file.load the same than spectrum.load.image? I mean, if an application
> wants to send to VOSpec a Fits file, can it send this spectra with both
> messages? Do I have to give support to both messages for one single event?
> The same with table.load and spectrum.load.table.
>  Of course better many than anything :-), but maybe I miss something.  I'd
> rather to have the MType "spectrum" consistent, in the meaning that I don't
> have to see which messages can be used for one single event, but just go to
> spectrum and see what I have. So, as in the previous message, I would
> suggest to include in the "spectrum" MType more diversification.

    The idea is that file.load is much more generic in meaning that
spectrum.load.image.
They may end up doing the same thing in the application and you might want to
subscribe to both mtypes, but where they differ is that with spectrum.load.image
you know the argument will be an image file containing a spectrum,
with file.load
you need to figure out whether this is an image or a table you can read.

    In my opinion, table.load.spectrum and spectrum.load.table would do the same
thing but I'm not entirely happy that we are allowing this kind of
aliasing and would
be open to suggestions about how/whether to avoid this.

    Note the spectrum MTypes are currently biased towards 1-D spectra, we might
also want to consider what to do for echelle or fiber spectra where we
might have
different arguments to specify the order (e.g.
spectrum.load.echelle.image).  Apps
are free to make up their own MTypes as needed, but if this will be a
common case
then it would be better to define the MTypes now so we all have a common
understanding of how to use them.

Cheers,
-Mike