TAP questions

Mark Taylor m.b.taylor at bristol.ac.uk
Fri Mar 9 10:39:15 CET 2018


On Fri, 9 Mar 2018, Markus Demleitner wrote:

> On Fri, Mar 09, 2018 at 12:45:31AM +0000, Dave Morris wrote:
> > 
> > On 2018-03-07 08:52, Markus Demleitner wrote:
> > > 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.
> > > 
> > 
> > There are cases where users will want to process the results as XML,
> > possibly using something like an XSLT parser, in which case they will want
> > some way to be able to specify the XML form.
> 
> Hm.  This is what VOTable 1.3 says:
> 
>   This type may be accompanied by an optional parameter "serialization"
>   with a value specifying the serialization type used for table data
>   within the document, one of TABLEDATA, FITS, BINARY or BINARY2,
>   interpreted case-insensitively. In the absence of this parameter, any
>   of the serializations may be encountered. If multiple different
>   serializations are used in the same document, this parameter must not
>   be used.
> 
> It's pretty clear to me from this language that a client can have no
> expectations in general that a given service must be able to produce
> serialization=TABLEDATA just because it's producing VOTable.  And I
> think there's no way VOTable could change this with reasonable
> specification effort.

Just to muddly the waters further, I know at least one place where
TABLEDATA is mandated; DataLink 1.0 sec 2.1.2 says:

   "The only output format required by this specification is VOTable 
    with TABLEDATA serialization [5]; services must support this format."

--
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/


More information about the dal mailing list