VOTable alternative?

[Tony Linde]

> > Ultimately, VOTable works because it can describe external, binary 
> > formats that are never addressable by XPath.  If we replace 
> VOTable, 
> > then we need to retain this abaility.
> 
> Unfortunately, I'd have to agree with this one...

I thought FITS did this (and here I am really out of my depth). Wouldn't it
be easier to stick with FITS for binary data (or enhance it if it doesn't
describe metadata adequately) and XML Schema / XML for documents in xml
format? It shouldn't be too difficult to come up with a conversion utility
so that in converting from binary to xml you convert the metadata to xml
schema and the data to xml.

Cheers,
Tony. 

> -----Original Message-----
> From: Alasdair Allan [mailto:aa at astro.ex.ac.uk] 
> Sent: 19 January 2004 13:58
> To: Guy Rixon
> Cc: Tony Linde; votable at ivoa.net
> Subject: Re: VOTable alternative?
> 
> 
> 
> > > Is anyone interested in an activity to come up with an 
> *alternative* 
> > > to VOTable?
> > > 
> > > I'm concerned that VOTable is contrary to the normal 
> usage of xml, 
> > > eg: the metadata for a table is in a proprietary format 
> rather than 
> > > in XML Schema;  it is embedded within the document; all 
> table data 
> > > is contained within TD elements making it impossible to 
> use normal 
> > > xml querying mechanisms.
> 
> I think you'll find people very reluctant at this stage to do 
> such a radical rethink. Were reaching the stage where people 
> have time and effort invested in parsing software, as the 
> show of hands in the IVOA meeting in Strasburg illustrated, 
> while we haven't quite reached the stage where we're in a 
> FITS-type lockin, its getting there. If we are going to do 
> something this radical we really have to do it soon, and with 
> the agreement of all the major players.
> 
> That said, I've been very concerned with the fact that we're moving 
> towards something that isn't parsable using standard XML 
> tools. Indeed, most of the suggestions discussed at the 
> VOTable working group in 
> Strasburg would move us even further away from something that 
> could be parsed with standard tools.
> 
> > I would support redefining VOTable for simplicity of 
> parsing.  At the 
> > last interop meeting I proposed a lightweight "profile" of VOTable.
> > I'd like to discontinue the use of embedded binary and to reduce the
> > variety of thngs that get put into table cells.
> 
> A subset schema? Yes, I remember yu talking about it. That 
> would certainly be a step in the right direction, there will 
> be quite a few libraries floating around that don't support 
> all of the features in VOTable, if we can give people a well 
> defined subset of features to support then these lightweight 
> libraries would at least have a standard to work on rather 
> than having them all support a _different_ subset of features 
> (shades of 
> the JFIF and TIFF debates here, and lets not talk about FITS readers).
> 
> > Changing the TD elements to something else is interesting but might 
> > not be feasible.  If we had a schema with a few x 10**3 kinds of 
> > elements that could appear inside a TABLEDATA (i.e. one for every 
> > possible UCD) would it work or would it crawl? Could a TD 
> element have 
> > a link to its ruling FIELD element? (I.e. can we make the 
> contents of 
> > FIELD accessible to XPath via TD?)
> 
> Err, pass? Anyone?
> 
> > Ultimately, VOTable works because it can describe external, binary 
> > formats that are never addressable by XPath.  If we replace 
> VOTable, 
> > then we need to retain this abaility.
> 
> Unfortunately, I'd have to agree with this one...
> 
> Al.
> -- 
> Dr. A. Allan, School of Physics, University of Exeter
>