TAP questions

[Dobos, László]

Sending an Accept-Encoding is indeed a good idea, thanks for the tip.

-L

-----Original Message-----
From: Mark Taylor [mailto:m.b.taylor at bristol.ac.uk] 
Sent: Wednesday, March 7, 2018 10:33 AM
To: Dobos, László <dobos at complex.elte.hu>
Cc: dal at ivoa.net
Subject: RE: TAP questions

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-plenar
y.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/