TAP questions

[Markus Demleitner]

Hi Laszlo,

On Tue, Mar 06, 2018 at 06:06:21PM +0100, Dobos, László wrote:
> Thanks for the answer, this is what I ended up doing. Some clarification
> about non-table (i.e. binary) serializations in the standard would also be
> great, in case you want to select the less verbose representation instead of
> the default votable-xml. This is where I ran into the problem.

Well, so far in the VO we do not really distinguish between the
various VOTable serialisations, except perhaps that external FITS
entities may confuse many libraries.  So, if you're ordering VOTable,
there's no guarantees whether you'll get back BINARY or TABLEDATA.

Mainly to cope with the transition from BINARY to BINARY2, we've
introduced the serialisation parameter to the VOTable media type,
which is by no means mandatory in the sense that you can reliably
tell from the content-type of an HTTP response what to expect in a
DATA element (where, of course, it's altogether legal to use
different serialisations in different TABLEs of the same VOTable).  

I suspect it's still a good idea to not produce BINARY2 without being
asked for it (via RESPONSEFORMAT/FORMAT).

The bottom line is: Any VOTable consumer these days should support
TABLEDATA, BINARY, and BINARY2.  I've not seen much DATA/FITS in the
wild, and I don't think that will change until perhaps people use
something like that to give FITS tables (images, even?) VO-DML
annotation.

If you're willing to do content negotiation, I'd prefer BINARY2 over
TABLEDATA over BINARY, based on the value of the serialization
parameter you see in outputFormats.  That preference based on my
personal assessment and mix of robustness with NULL values, bit-exact
representation, and general compactness (where, incidentally,
TABLEDATA isn't much larger than BINARYx if piped through gzip).

        -- Markus