TAP questions

[Mark Taylor]

One other pragmatic point related to that: although TABLEDATA is
much loathed for its verbosity, it actually compresses quite well. 
In my tests (e.g. reported briefly at
http://wiki.ivoa.net/internal/IVOA/InterOpMay2012Applications/votable-plenary.pdf)
I've found that gzipped TABLEDATA tends to be a bit smaller
than uncompressed BINARY.  So if it's the number of bytes over the
wire that you're concerned about, you might consider instead
requesting/honouring requests with the HTTP header
Accept-Encoding: gzip.

On Tue, 6 Mar 2018, Dobos, László wrote:

> Hi Mark,
> 
> 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.
> 
> -Laszlo
> 
> -----Original Message-----
> From: Mark Taylor [mailto:m.b.taylor at bristol.ac.uk] 
> Sent: Tuesday, March 6, 2018 11:57 AM
> To: Dobos, László <dobos at complex.elte.hu>
> Cc: dal at ivoa.net
> Subject: Re: TAP questions
> 
> Laszlo,
> 
> I don't think Markus answered your question (5) about response formats:
> 
> On Wed, 28 Feb 2018, Dobos, László wrote:
> 
> > 5. What is the suggested way of figuring out the list of supported 
> > output formats? There seems to be no standard list of mime types. For 
> > example the gaia tap interface at 
> > "http://gaia.ari.uni-heidelberg.de/tap/ offers this
> > list:
> > 
> >               <outputFormat>
> >                             <mime>application/x-votable+xml</mime>
> >                             <alias>votable</alias>
> >               </outputFormat>
> >               <outputFormat>
> > <mime>application/x-votable+xml;serialization=BINARY2</mime>
> >                             <alias>votable/b2</alias>
> >               </outputFormat>
> >               <outputFormat>
> > <mime>application/x-votable+xml;serialization=TABLEDATA</mime>
> >                             <alias>votable/td</alias>
> >               </outputFormat>
> >               <outputFormat>
> > <mime>application/x-votable+xml;serialization=FITS</mime>
> >                             <alias>votable/fits</alias>
> >               </outputFormat>
> >               <outputFormat>
> >                             <mime>application/fits</mime>
> >                             <alias>fits</alias>
> >               </outputFormat>
> >               <outputFormat>
> >                             <mime>application/json</mime>
> >                             <alias>json</alias>
> >               </outputFormat>
> >               <outputFormat>
> >                             <mime>text/csv</mime>
> >                             <alias>csv</alias>
> >               </outputFormat>
> >               <outputFormat>
> >                             <mime>text/tab-separated-values</mime>
> >                             <alias>tsv</alias>
> >               </outputFormat>
> >               <outputFormat>
> >                             <mime>text/plain</mime>
> >                             <alias>text</alias>
> >               </outputFormat>
> >               <outputFormat>
> >                             <mime>text/html</mime>
> >                             <alias>html</alias>
> >               </outputFormat>
> > 
> > whereas other services (e.g. vizier) use different mime types and some 
> > don't even provide the aliases. Are the aliases standardized so I can 
> > select the best format based on that or I need to do some heuristics 
> > based on the mime type strings?
> 
> I don't believe there is a straightforward answer to the question as posed,
> but the key point is that the VOTable format is the default, and that TAP
> services are required to support it.  Other formats are an optional extra,
> and their MIME-type labels are not tightly constrained.
> 
> So if you are implementing a service, make sure that VOTable is provided,
> and if you are consuming a service (I think this is where your concern comes
> from) just omit the FORMAT/RESPONSEFORMAT request parameter and you can
> assume you will get VOTable responses.
> 
> This fact is clear from section 2.3.6 of TAP 1.0:
> 
>    "If the FORMAT parameter is omitted, the default format is VOTable.
>     A TAP service must support VOTable as an output format, should
>     support CSV and TSV output and may support other formats."
> 
> However, the equivalent section of PR-TAP-1.1-20170830, sec 2.7.3, says
> only:
> 
>    "The RESPONSEFORMAT parameter is fully described in [DALI 1.1].
>     For backwards compatibility, TAP-1.1 must also accept the FORMAT
>     parameter as equivalent to RESPONSEFORMAT."
> 
> As far as I can see, DALI does not say anything about VOTable being
> required, and in fact in sec 2.7.3 says:
> 
>    "A concrete DAL service specification will specify any mandatory
>     or optional formats as well as new formats not listed above"
> 
> So if you were looking at TAP 1.1 for implementation, I'm not surprised you
> had trouble here.
> 
> ACTION:
> ------
> I therefore believe a fix is required to TAP 1.1: sec 2.3.6 should make it
> clear that VOTable support is mandatory (and possibly that CSV is a SHOULD
> for compatibility with TAP 1.0), and that VOTable is the default output
> format when FORMAT/RESPONSEFORMAT parameter is not explicitly specified.
> 
> Mark
> 
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/