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