> However nobody is using the binary represnetation, and we could decide
> to abandon it.
While nobody is using it in anger (yet?) I think its crucial to keep around, at least at the level of having a URI pointing to a binary file (presuambly FITS) sitting somewhere else, rather than having to have the table data inline in the XML. Alot of the time people are _only_ intersted in the in meta data. This saves pushing 10Gb files around when we really don't have to... but you know all that! ;)
> (b) There is a different schema for each table, so it is difficult to
> make tools that work with generic tables. VOPLot and Mirage make
> visualizations from ANY VOtable.
I really don't like the idea of having a different schema for each table, I can see why some people are argueing for it, but I think it breaks the paradigm (and makes things tricky for people trying to read everything).
> Finally let me say that the VOTable confusion comes from the
> <TABLEDATA><TR><TD> elements. I think the best thing would be to
> remove them from the spec.
Err, no? While I agree with you in principle, for _small_ tables I just want to push an XML file around, I don't want to have to have a FITS file sitting at some URI holding 5 lines of table that fufil a query. Having someway to put small simple tables into XML is vital. That said I don't like the <TABLEDATA><TR><TD> element approach, I just think its necessary to have something that does the job (unfortunately)
Of course, so is having someway to stop people putting 10Gb of data inline using the same XML (baseball bats perhaps?).
Al.
-- Dr. A. Allan, School of Physics, University of ExeterReceived on 2004-01-19Z15:44:17