Comments on V1.1 - Future of VOTable (flame bait sigh)

[martin hill]

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.net