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

[Mark Taylor]

On Wed, 14 Apr 2004, martin hill wrote:

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

I agree that type safety is, other things being equal, a good thing, 
and there are costs to using a single format (VOTable) to describe 
all our tabular data.  But there are costs to the opposite approach as well. 
It is *not* true that:
 
> 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!). 

An important bit of effort which is saved is coming up with facilities for
dealing with, crudely, columns of numbers.  Schemas are not designed to
represent tables, and though there are plenty of industry-standard tools
for doing computer-science-type tasks with them (validation, web service
specification, searching), the same is not true (as far as I'm aware)
for astronomy-type tasks which rely on the tabular nature of the data
(plotting columns against each other, converting to a FITS table or other
tabular format for use with legacy applications, calculating statistics).
An important related point is that VOTable provides ways of storing and
transmitting very large data sets for which raw XML is not well suited
in terms of bandwidth and/or processing efficiency.

If a SED is passed around as a VOTable then the application programmer
can use an existing VOTable processing library to turn it into something
which looks like a column of numbers for further processing without 
further ado, or the astronomer can use a VOTable-aware tool to do 
something tabularly-generic with it such as plot.  If it's passed 
around using a SED-specific schema this functionality has to be 
rewritten from scratch for SEDs (and the same applies for any other
specific formats that we want to define new schemas for).

Mark

PS:

> I have been assuming that VOTable is for representing 2d tables (I realise it 
> can now hold tables that include tables).

If I understand this statement correctly, I don't think it's true.

-- 
Mark Taylor    Starlink Programmer     Physics,  Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/