VOTable alternative?

[awicenec at eso.org]

Quoting Tony Linde <ael at star.le.ac.uk>:

> > Perhaps you should enlighten us on the benefits of using XML 
> > technology for the community. I don't have a position either 
> > pro or con XML.
> 
> I'm no xml guru but I figure if we're going to use xml, we should do so
> properly. The VOTable format seems to combine the space inefficiencies of
> xml with the interpreting inefficiencies of csv: without much added benefit.
> 
> I guess the key benefit to using xml is taking advantage of the huge
> investments in developing tools and technologies to query, index, compress,
> store etc documents in this format. None of which we can take advantage of
> with the current VOTable format (IMO).

I agree partially, because all depends on how you want to use the data
afterwards. If you really want to use XML tools to deal with the data itself the
TR/TD stuff is almost useless and even more so he more 'advanced' options of
coding the data as encoded binary blobs or even as pure binary. But the picture
is very different if you are using XML tools to just deal with the metadata
part. There it is indeed feasible to use standard tools and parsing mechanisms,
but there are still some caveats with the current VOTable even in the metadata
section. Anyway I guess that most packages would implement quite specific things
to deal with huge amounts of tabular (or other) data. Anyway it would be pretty
simple to do what Anita and Roy seem to favour: Using some automatically created
software (e.g. XSL code) you can in fact convert a VOTable to a fully tagged XML
file which then can be treated using standard XML tools. The main advantage I
see with VOTable is in fact that we are able to go further than just describing
formats, but in fact we are already in the regime of semantics and onthologies.
The problem in my view is just that all that got mixed-up in our VOTable header
using plain XML syntax. 

> 
> > - In its current format, VOTable is human understandable and 
> > the metadata
> >   can be easily followed.
> 
> That is where I differ. Take any VOTable document, look at any of the data
> itself and it is meaningless unless you first read the metadata and figure
> out which TD in a row is which field.

Well, it is very much like any printed or otherwise published table and that's
probably why most people involved here like and understand VOTable the way it
is: There is something like a header row prior to the data rows, which in
principle just give a name (and some additional nice things) to the columns of
the table. Since that's a very common way to present tables to human users
everybody can actually interpret the values given in the <TD> elements. I agree
that this is very different for standard XML tools, which are much better if
every field is explicitely tagged. That's why I think we should allow for
different representations of a certain instance of a VOTable. Representations on
the other hand are the domain of XSLT and this should certainly not be mixed
into the VOTable schema as such.

BTW: As many people already pointed out there is no valid VOTable Schema as of
now, maybe we should first concentrate on trying to produce this. I think
everybody would agree that we should indeed have a Schema file which can be used
by standard parsers and XSD tools.

Andreas