> 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.
Note that this allows "3h 47m 36.3s" as a valid string, but not as a valid float or double.
Roy
California Institute of Technology
626 395 3670
Received on 2006-04-20Z21:48:17