Clive Page wrote:
> Alasdair Allan wrote:
> > Yes, FITS became a storage and processing format, however it was (and
> > still isn't) particularly good at those jobs...
>
> I agree with all your remarks, Alasdair. I wasn't saying that FITS was
> well-designed as a storage format (that's nobody's fault, it wasn't ever
> designed with this in mind). I agree we should try to design something
> better, although we may have differences of opinion as to whether VOTable
> is a step along the way, as it's also designed as a data _transport_
> format.
I would suggest that VOTable is just that, a _transport_ format. It's a piece of XML we should use to push (relaitively) small catalogues around various web and grid services.
We shouldn't use VOTable to serialise our data models, there are perfectly good industry standard tools available to serialise object models, however as a generic transport format it's perfectly acceptable.
People are talking about overloading VOTable to handle SED, spectra and time series data. I feel that this is a bad idea, we're overloading the format too heavily. One tool for one job.
> No, I was just pointing out the sort of features that VOTable needs to
> support have before it can be taken as anywhere near mature.
I think this depends very critically on what VOTable is for, I've yet to heara clear statement of this that isn't immediately contradicted by someone else.
> These ad hoc conventions grew up partly because the official FITS
> standardisation process was so cumbersome.
Agreed, the VO needs to steer clear of anything that even vaguely looks like the FITS standardisation process, it was a clear failure.
> Actually a good way of setting up a "standard" is for two (or more)
> places to agree something and interchange data using it.
Actually thats a horrible way to set up a standard, unfortunately it's the most common way...
> That's how FITS started.
I think you just made my point for me...
Al.
-- Dr. A. Allan, School of Physics, University of ExeterReceived on 2004-04-14Z13:08:19