Quoting Alasdair Allan <aa-at-astro.ex.ac.uk>:
>
> 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.
>
Hmmm, why shouldn't a transport format not also be used as a storage format?
> 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.
Nooooo... etc. It's *worse* as a generic transport format! See below...
>
> 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.
> <snip>
> 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.
I have been assuming that VOTable is for representing 2d tables (I realise it can now hold tables that include tables).
That's it.
The schema says nothing about the data type; this is an advantage (we can have a standard agreed) and a disadvantage (the standard is too vague to be useful in practice).
Let us say we have two web services; the first takes a query, submits it to several datacenters, and returns an SED. The second takes an SED, combines it with a Sky Catalogue to produce an extended SED.
WSDLs and schemas exist to explicitly describe these things; you can say that a service expects an SED and a Sky Catalogue and people and software examining that interface will see that.
If we describe everything using VOTable, there is no way of knowing we are connecting the above two services up correctly. We can quite happily wire it up so that the SED is passed in as the Sky Catalogue to the second service. This is Bad. Bypassing the WSDL/schema technologies with our own invention is Really Bad.
Nor do we save any effort in using VOTable to represent SEDs than in writing a new SED schema (except maybe for a few people to learn schemas - but this is no harder than learning VOTable and it's a good skill to have!).
So lets mark VOTable as a standard output for all services *for now* while we work on future data formats for both transport and storage. Let's extend it to include new metadata developments. Let's write a few tools to manipulate it. But let's think of it as a CSV-with-metadata and concentrate on getting useful formats together.
Cheers,
Martin
-- Martin Hill 07901 55 24 66 www.mchill.netReceived on 2004-04-14Z15:00:29