>
> Anita Richards wrote:
> > Put another way, there is certainly the need for a standard, but that
> > should be independent of how it is implimented to describe FITS, VOTable,
> > ascii or whatever.
>
> In case of a data model it should indeed be independent of a particular
> implementation. But a data access layer without hooks to existing formats and
> protocols appears of little practical use. Therefore, it does make sense to
> keep in sync with the FITS community as far as data representation is
> concerned. If not we pay the price in terms of more complicated systems.
>
You are quite right - and maybe someone could give examples of actual teleescope data in formats which could (not) be handled effectively - e.g. Bob mentioned the large amount of single dish data which are simply ascii tables of flux density/T_A (possibly at 2 pols, possibly with other quantities) versus wavelength or equivalent e.g. chann. No (indeed not necessarily linearly or even regularly related to wavelength). However unless I ahve misunderstood the debate, there is no question that the data _can_ be handled, it is simply a question of how, and surely testing on real data (or at least a detailed thought experiment) is the way to proceed?
I agree with Markus that VOTable standards should recognise all standard FITS but is the reverse necessary? i.e. if VOTable can do more than FITS, is that a problem? So long as conversion in both directions is possible, but possibly with loss of information. What I am thinking of is:
FITS native spectrum > VOTable > FITS all original information restored
but some added info from VOTable
may be lost
but in both cases, is the lost information material which FITS handling tools can't cope with anyway? And if so, can't it be included as a VOTable wrapper (and also accessible in human readable form so you know aht is not accessble to your FITS tool but ou might like to know anyway?)
Or have I completely missed the point in whch case don't worry about replying, I will shut up and listen.
thanks
A