Comments on V1.1 - Future of VOTable (flame bait sigh)
mchill at dial.pipex.com
Wed Apr 14 06:00:02 PDT 2004
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.
> 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).
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
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
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
07901 55 24 66
More information about the votable