Hi Petr -
I agree that support for continuum normalized spectra is important, and am convinced by the arguments made that this is often just as useful for analysis as flux calibrated spectra.
I don't think the issue of continuum normalized spectra is adequately addressed in the documents currently, and we probably need to add some explicit mention of how to represent this case. This issue came up some time ago as well (for example see http://www.ivoa.net/forum/dm/0502/0929.htm). The suggestion at the time was that we use the UCD "phot.fluxDens;arith.ratio" to address this case (there is no UCD currently expressly for continuum normalized flux values, although we might want to consider adding in the future).
The suggestion to add "normalized" as a form of flux calibration is something we should consider. What do others think? Possibly this could also be considered as a case of relative or absolute flux calibration where the flux is a unitless ratio.
Regarding support for IRAF-Onedspec format for spectra (a linearized spectrum represented as a 1-D image), I feel this is too limited a format to be pushed as a new general standard, as we cannot express basic things such as errors, quality flags, variable spectral resolution, nonlinear dispersions, etc., with this format (although nonlinear dispersion support might be possible now that we have general FITS spectral WCS support).
Nonetheless, as you say a lot of client software accepts spectra in this form so perhaps we can find a way to deliver software in this form, and provide tools for publishing such software. The only thing is, to get VO spectra into a client application is an issue of more than the data format and data model. We also need client software which can form and issue a query to an SSA service, select spectra, and download them over the Internet; legacy software which is not yet VO-enabled probably cannot do all these things. Hence some new software will be required no matter what we do.
One simple solution the might be do do the conversion on the client side, and have an option to write out spectra locally in this format for consumption by legacy software. The advantage of this approach is that it would work for access to any SSA service regardless of what (standard) output formats it supports. It is certainly also possible for an SSA service to have the capability to return spectra in this format, but as I say, it is not general enough to be a core format. If a service supports 1-D images as an output format, this would be an optional capability indicated in the list of supported formats, and a query with FORMAT set to the appropriate MIME type (as in your email) would specify that this is the format the client wants back.
In the case of IRAF itself we are working already to interface IRAF directly to SSA, at which time it will be able to read Spectrum-DM compliant spectra directly, and all the IRAF tasks will be usable directly on VO-compliant spectra. Other tools such as VOSpec, SPLAT, Specview, etc. either already have this capability, or there are plans to add it. For other apps or environments, we have middleware such as VOClient in development which will make this easier in the future. Ultimately I think this is the best solution.
> Most of the spectra from ground
> are served by a single server tool (Pleinpot by P. Prugniel)
This sounds interesting - maybe we can get this software updated to support an SSA service interface. We have various other service toolkits either available now or in production (my own DALServer code for example) which could include support for directly publishing spectra in this format. Having several such ready to use toolkits is probably the best approach for making it easier for small data providers to publish such spectra.