On Thu, 20 Apr 2006, Roy Williams wrote:
> > It does point out a serious error/omission in the VOTable definition
> > though,
> > in Section 7. For the normal <TABLEDATA> representations that are
> > almost
> > exclusively used, the definitions of the primitives for types short,
> > long,
> > float, double and probably bit are all incorrect. We tried to define
> > how the data would be stored on the computer in terms of what it gets
> > parsed into, but if you don't know how to parse it, that's not very
> > helpful.
>
> As I've said before, the TABLEDATA thing was a hack added at the end of
> the process for "very very small tables". We had been fooled by the VO
> proposals which all started with the phrase about "avalanche of data",
> and so most of the effort was put into a table format that would pack
> the data into the smallest space -- i.e. the binary data encoding and
> the FITS table compatibility.
>
> Perhaps we can use an existing standard for the ascii parsing. How
> about saying that all ascii representations are acceptable so long as
> Java, Python, Perl and C can all recognize it? So you can say 3.5E-6 or
> 3.5e-6 but you can't say 3.5D-6.
As per one of my earlier messages, this is a non-issue, since it has been addressed properly in the current version (1.1) of the standard.
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2006-04-21Z11:02:00